On Sun, Jul 12, 2009 at 4:42 PM, Tom Lane<t...@sss.pgh.pa.us> wrote: > > I'm kind of wondering how big the use case for that really is. > AFAICT the point of a concurrent build is to (re)build an index > without incurring too much performance penalty for foreground > query processing. So how often are you really going to want > to fire off several of them in parallel? If you can afford to > saturate your machine with indexing work, you could use plain > index builds.
I don't really see those as comparable cases. Firing off multiple concurrent index builds only requires lots of available I/O throughput; using plain index builds requires a maintenance window where any updates to the table is shut down. Being able to run multiple concurrent index builds just means being able to roll out a schema change more quickly. It doesn't let you do anything that was impossible before. Another thing that's annoyed me about our current support for concurrent index builds is that you can't run multiple concurrent builds on the same table. Since they all take the strangely named ShareUpdateExclusiveLock you can only run one at a time. Fixing that would require introducing a new, uh, ShareUpdateSharedLock(?) which conflicts with the vacuum lock but not itself. It didn't seem worth introducing a new lock type at the time but with syncscanning and the evidence people are actually doing this I'm starting to wonder. -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers