Thom Brown wrote:
>
It looks like your statistics are way out of sync with the real data.
> Nested Loop (cost=885367.03..1123996.87 rows=8686 width=12) (actual
time=248577.879..253168.466 rows=347308 loops=1)
This shows that it thinks there will be 8,686 rows, but actually
traverses 347,308.
Yes, I see what you mean.
Have you manually run a VACUUM on these tables? Preferrably a full one
if you can.
Every night, it runs Vacuum verbose analyze on the entire database. We
also have the autovacuum daemon enabled (in the default config).
About 2 weeks ago, I ran cluster followed by vacuum full - which seemed
to help more than I'd expect.
[As I understand it, the statistics shouldn't change very much from day
to day, as long as the database workload remains roughly constant. What
we're actually doing is running a warehouse sorting books - so from one
day to the next the particular book changes, but the overall statistics
basically don't.]
I notice that you appear ot have multiple sorts going on.
Are all of those actually necessary for your output?
I think so. I didn't actually write all of this, so I can't be certain.
Also consider
using partial or multicolumn indexes where useful.
Already done that. The query was originally pretty quick, with a few
weeks worth of data, but not now. (after a few months). The times don't
rise gradually, but have a very sudden knee.
And which version of PostgreSQL are you using?
8.4.1, including this patch:
http://archives.postgresql.org/pgsql-bugs/2009-10/msg00118.php
Richard
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
