From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at> |
Cc: | "Wes" <wespvp(at)syntegra(dot)com>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [GENERAL] Concurrency problem building indexes |
Date: | 2006-04-25 14:58:05 |
Message-ID: | 19159.1145977085@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at> writes:
> My answer to this would be to (have an option to) ommit this relpages
> and reltuples update.
Wouldn't help, unless you want to get rid of relhasindex too.
> Wes, you could most likely solve your immediate problem if you did an
> analyze before creating the indexes.
No, because that would install an approximate tuple count that the first
CREATE INDEX would (most likely) still want to replace.
The best I can gather from Wes' mail is that he's somehow getting a
higher-than-chance probability that the first two CREATE INDEX commands
finish at almost exactly the same time, and thus neither one of them
sees the pg_class row as already updated with the correct values.
I can't think of any effect in the PG code that would make CREATE INDEX
commands tend to converge rather than diverge, so maybe there is some
external effect here. Wes, is your machine a dual processor by any
chance? Which OS X version exactly?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2006-04-25 15:09:10 | Re: Google SoC--Idea Request |
Previous Message | Zeugswetter Andreas DCP SD | 2006-04-25 14:55:00 | Re: [GENERAL] Concurrency problem building indexes |