Re: Any better plan for this query?..

From: Matthew Wakeling <matthew(at)flymine(dot)org>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Dimitri <dimitrik(dot)fr(at)gmail(dot)com>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Any better plan for this query?..
Date: 2009-05-06 09:35:50
Message-ID: alpine.DEB.2.00.0905061030590.2341@aragorn.flymine.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Merlin Moncure 2009-05-06 11:46:05 Re: Any better plan for this query?..
Previous Message Richard Huxton 2009-05-06 09:02:29 Re: Any better plan for this query?..