On Wed, 6 May 2009, Heikki Linnakangas wrote:
Total runtime: 1.442 ms
It's pretty clear that this query isn't even going to disc - it's all CPU time. That can be the case if you run the exact same query more than once, and it can cause your EXPLAIN output to be vastly different from your real use case. Do the queries on the live system hit the disc at all?
The bad doesn't look too bad to me, although the planner is over-estimating the number of matches in the history table (2404 vs 20). That's a bit surprising given how simple the predicate is. Make sure you've ANALYZEd the table. If that's not enough, you can try to increase the statistics target for ref_object column, ie. ALTER TABLE history ALTER COLUMN ref_object SET STATISTICS 500.
I would have thought this would actually make it slower, by increasing the time taken to plan. On such small queries, the planner overhead must be quite significant.
Matthew -- Q: What's the difference between ignorance and apathy? A: I don't know, and I don't care. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
