Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: strange buildfarm failure on lionfish


  • From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
  • To: Gregory Stark <stark(at)enterprisedb(dot)com>
  • Cc: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Stefan Kaltenbrunner" <stefan(at)kaltenbrunner(dot)cc>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
  • Subject: Re: strange buildfarm failure on lionfish
  • Date: Tue, 24 Jul 2007 15:49:33 -0400
  • Message-id: <15228(dot)1185306573(at)sss(dot)pgh(dot)pa(dot)us>

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>>> Gregory Stark wrote:
>>>> What really has to happen is it should run analyze on all tables
>>>> together in a single transaction and commit all the new stats together.
>>>> Out-of-sync stats can be worse than out-of-date stats.
>> 
>>> One problem with that is that it will keep the locks on each table until
>>> the end of all analyzes.
>> 
>> Yeah, that seems entirely infeasible, even if I agreed with the premise
>> which I don't think I do.

> Well that's just what ANALYZE with no arguments at all does.

Not unless you wrap it in a transaction block --- otherwise it does a
transaction per table.  If you try wrapping it in a transaction block
on a production system, you'll soon find you don't like it.

			regards, tom lane



Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group