From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Sam Liddicott" <sam(dot)liddicott(at)ananova(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: 7.2.1 optimises very badly against 7.2 |
Date: | 2002-06-28 14:12:49 |
Message-ID: | 3704.1025273569@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Sam Liddicott" <sam(dot)liddicott(at)ananova(dot)com> writes:
> Under 7.2.1 it takes 99% CPU for between 5-9 seconds.
> Rolling back to 7.2 is also very slow unless we vacuum analyse after rolling
> back, then it is very fast again.
> [We normally vacuum analyse every 24 hours]
AFAIK, the only change from 7.2 to 7.2.1 that would be likely to have
anything to do with this was a rework of the code in ANALYZE that
estimates the number of distinct values in a column. (See pghackers
archives from around 18-Feb.) Although the revised version did better
on some test cases, it sounds like it's doing worse for you.
As Nigel commented, we can't do much without seeing EXPLAIN ANALYZE
results. I'd also like to see the pg_stats entries for the table(s)
used by the query, as produced by both 7.2 ANALYZE and 7.2.1 ANALYZE.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-06-28 14:19:50 | Re: createdb error |
Previous Message | Neil Conway | 2002-06-28 14:09:47 | Re: One source of constant annoyance identified |