Re: REINDEX CONCURRENTLY 2.0

Thanks for the feedback. I will look at it when I get the time.

On 03/31/2017 08:27 AM, Michael Paquier wrote:
> - Do a per-index rebuild and not a per-relation rebuild for concurrent
> indexing. Doing a per-relation reindex has the disadvantage that many
> objects need to be created at the same time, and in the case of
> REINDEX CONCURRENTLY time of the operation is not what matters, it is
> how intrusive the operation is. Relations with many indexes would also
> result in much object locks taken at each step.

I am personally worried about the amount time spent waiting for long
running transactions if you reindex per index rather than per relation.
Because when you for one index wait on long running transactions nothing
prevents new long transaction from starting, which we will have to wait
for while reindexing the next index. If your database has many long
running transactions more time will be spent waiting than the time spent
working.

Are the number of locks really a big deal compared to other costs
involved here? REINDEX does a lot of expensive things like staring
transactions, taking snapshots, scanning large tables, building a new
index, etc. The trade off I see is between temporary disk usage and time
spent waiting for transactions, and doing the REINDEX per relation
allows for flexibility since people can still explicitly reindex per
index of they want to.

Andreas