Re: Is Vacuum/analyze destroying my performance?
От | Carlo Stonebanks |
---|---|
Тема | Re: Is Vacuum/analyze destroying my performance? |
Дата | |
Msg-id | el1kmi$t75$1@news.hub.org обсуждение исходный текст |
Ответ на | Is Vacuum/analyze destroying my performance? ("Carlo Stonebanks" <stonec.register@sympatico.ca>) |
Ответы |
Re: Is Vacuum/analyze destroying my performance?
|
Список | pgsql-performance |
""Matthew O'Connor"" <matthew@zeut.net> wrote in message news:45743240.7050302@zeut.net... > 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.
В списке pgsql-performance по дате отправления: