Re: Catalog Access (was: [GENERAL] Concurrency problem

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Wes <wespvp(at)syntegra(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Hannu Krosing <hannu(at)skype(dot)net>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Zeugswetter Andreas DCP SD <ZeugswetterA(at)spardat(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Catalog Access (was: [GENERAL] Concurrency problem
Date: 2006-04-26 23:21:56
Message-ID: 20060426232156.GK97354@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 26, 2006 at 07:13:08PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
> > What about not updating if the tuplecount is within X percent? Would
> > that be safe enough to back-port?
>
> Even if you got agreement that it was a good idea (I don't think so
> myself), it wouldn't help Wes, at least not for values of X smaller
> than 100. Presumably, that first CREATE INDEX is trying to update
> reltuples from zero to reality.

It may be, but an ANALYZE would eliminate that need and be far faster
than waiting on one entire CREATE INDEX. I'm thinking that even being of
by as much as 5% won't matter to the planner, and I can't think of any
possible reason to need an exact tuplecount in pg_class...

> Also, the first CREATE INDEX has to set relhasindex = true, and that's
> not fuzzy at all.

Oh, will each index build try and do that? Would changing that be
non-invasive enough to backpatch (I'm guessing it's just an added
conditional...)
--
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 Tom Lane 2006-04-27 00:13:21 Re: ANSI-strict pointer aliasing rules
Previous Message Wes 2006-04-26 23:19:26 Re: Catalog Access (was: [GENERAL] Concurrency problem