It makes more sense for us to have ~1 hour's worth of reindexing afterwards during which read performance on that partition is "compromised".
So, based on the docs, I was expecting read performance to be compromised during a reindex, specifically reads would not be allowed to use the index:
"REINDEX locks out writes but not reads of the index's parent table. It also takes an exclusive lock on the specific index being processed, which will block reads that attempt to use that index."
However I'm seeing that all readers of that table are blocked until the reindex finishes, even reads that do not attempt to use the index. Is this a problem with the docs or a bug?
I'm considering creating a new index with the same definition as the first (different name), so while that index is being created, read access to the table, and the original index, is not blocked. When the new index is created, drop the original index and rename the new index to the original, and we've essentially accomplished the same thing. In fact, why isn't reindex doing this sort of thing in the background anways?
Thanks,
Steve
