Roman,
First, if this is a dedicated PostgreSQL server, you should try increasing
your shared_buffers to at least 512mb (65536) if not 1GB (double that) and
adjust your shmmax and shmmall to match.
Second, you will probably want to increase your sort_mem as well. How much
depeneds on the number of concurrent queries you expect to be running and
their relative complexity. Give me that information, and I'll offer you
some suggestions. Part of your slow query
Your query problem is hopefully relatively easy. The following clause is 95%
of your query time:
> -> Index Scan using
batchdetail_ix_tranamount_idx on batchdetail d (cost=0.00..176768.18
rows=44010 width=293) (actual time=35.48..1104625.54 rows=370307 loops=1)
>
See the actual time figures? This one clause is taking 1,104,590 msec!
Now, why?
Well, look at the cost estimate figures in contrast to the actual row count:
estimate rows = 44,010 real rows 370,307
That's off by a factor of 9. This index scan is obviously very cumbersome
and is slowing the query down. Probably it should be using a seq scan
instead ... my guess is, you haven't run ANALYZE in a while and the incorrect
row estimate is causing the parser to choose a very slow index scan.
Try running ANALYZE on your database and re-running the query. Also try
using REINDEX on batchdetail_ix_tranamount_idx .
Second, this clause near the bottom:
-> Seq Scan on purc1 p1 (cost=0.00..44259.70
rows=938770 width=19) (actual time=98.09..4187.32 rows=938770 loops=5)
... suggests that you could save an additional 4 seconds by figuring out a way
for the criteria on purc1 to use a relevant index -- but only after you've
solved the problem with batchdetail_ix_tranamount_idx.
Finally, if you really want help, post the query.
--
-Josh Berkus
Aglio Database Solutions
San Francisco