From: | "Carlo Stonebanks" <stonec(dot)register(at)sympatico(dot)ca> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Is Vacuum/analyze destroying my performance? |
Date: | 2006-12-04 17:08:42 |
Message-ID: | el1kmi$t75$1@news.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
""Matthew O'Connor"" <matthew(at)zeut(dot)net> wrote in message
news:45743240(dot)7050302(at)zeut(dot)net(dot)(dot)(dot)
> Just a wild guess, but the performance problem sounds like maybe as your
> data changes, eventually the planner moves some query from an index scan
> to a sequential scan, do you have any details on what queries are taking
> so long when things are running slow? You can turn on the GUC var
> "log_min_duration_statement" and see what queries are slow and then
> manually check them with an explain analyze, that might help.
>
> Matt
This is pretty well what I think is happening - I expect all queries to
eventually move from seq scans to index scans. I actually have a SQL logging
opion built into the import app.
I just can't figure out how the planner can be so wrong. We are running a 4
CPU server (two dual core 3.2 GHz Xeons) with 4GB RAM and Windows Server
2003 x64 and a PERC RAID subsystem (I don't know the RAID type). I know that
the metrics for the planner can be changed - is the default config for
postgesql not suitable for our setup? For this server, we would like to be
optimised for high speed over a few connections, rather than the classic
balanced speed over many connections.
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Lonsdale | 2006-12-04 17:10:59 | Configuration settings for 32GB RAM server |
Previous Message | Arjen van der Meijden | 2006-12-04 16:41:14 | Re: 8.2rc1 (much) slower than 8.2dev? |