Alvaro, * Alex Turner ([EMAIL PROTECTED]) wrote: > The other thing is you will probably want to turn on stats in postgres to > figure out which queries are the bad ones (does anyone have good docs posted > for this?). Once you have identified the bad queries, you can explain > analyze them, and figure out why they suck.
Given your position, this might be the best approach to take to find
some 'low-hanging fruit'. Do you have queries which are complex in some
way? Do you have many long-open transactions? If you're doing more
than simple queries then you may want to explain analyze the more
complex ones and try to speed them up. If you run into trouble
understanding the output or how to improve it then post it here (with as
much info as you can, schema definitions, the query, the explain analyze
results, etc) and we can help.
top/iostat/vmstat are very useful tools too and can help with hardware
decisions but you probably want to review your queries and make sure the
database is performing as best it can with the setup you have today
before throwing more hardware at it.
Thanks,
Stephen
signature.asc
Description: Digital signature
