Re: concurrent index builds unneeded lock?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Theo Schlossnagle <jesus(at)omniti(dot)com>, PostgreSQL-development Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: concurrent index builds unneeded lock?
Date: 2009-07-12 15:42:30
Message-ID: 16007.1247413350@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <gsstark(at)mit(dot)edu> writes:
> So I think we're back to looking at a special case for concurrent
> index builds to not wait on other concurrent index builds.

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-07-12 15:51:20 Re: concurrent index builds unneeded lock?
Previous Message Greg Stark 2009-07-12 15:29:41 Re: concurrent index builds unneeded lock?