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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
