Re: Tricky bugs in concurrent index build

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Gregory Stark <stark(at)enterprisedb(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Tricky bugs in concurrent index build
Date: 2006-08-26 01:05:09
Message-ID: 20060826010509.GE73562@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 25, 2006 at 11:25:43AM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > The problem is that what the qualifier is doing is modifying the
> > operation itself, not the properties of the index to be created, like
> > UNIQUE, which modifies the index.
>
> Right, which was the same point Bruce made earlier. And really you
> can't respect that difference while putting them into the same place in
> the word order. So I'm starting to feel like maybe we should leave
> well enough alone.

Since we might eventually have other 'concurrent commands', perhaps

CONCURRENT CREATE INDEX ...

would be best.

BTW, if we started to consider lazy vacuum a concurrent command we could
ditch the use of FULL, which is always confusing if you're talking about
database-wide vacuums. I know it'd take many versions to fully make that
change, but it seems worth it to me to reduce confusion. There's also an
issue of newbies thinking they should use vacuum full regularly because
it's somehow better than lazyvac.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Euler Taveira de Oliveira 2006-08-26 01:15:02 Re: [HACKERS] New XML section for documentation
Previous Message Jim C. Nasby 2006-08-26 01:02:21 Re: Tricky bugs in concurrent index build