Re: Query runs fast or slow - Mailing list pgsql-general

From felix@crowfix.com
Subject Re: Query runs fast or slow
Date
Msg-id 20060417024723.GA6234@crowfix.com
Whole thread Raw
In response to Re: Query runs fast or slow  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Sun, Apr 16, 2006 at 04:32:25PM -0400, Tom Lane wrote:

> To analyze the plan used for a parameterized query, try
>
>     PREPARE foo(...) AS SELECT ... $n ...
>
>     EXPLAIN ANALYZE EXECUTE foo(...)
>
> But I already know what you're going to find: the planner's estimates
> for the range query are not going to be very good when it has no idea
> what the range bounds are.  This is a situation where it may be best
> to absorb the hit of re-planning each time instead of using a generic
> parameterized plan.

I will try this Monday, but isn't 75 seconds an awful long time?  It
almost seems like even the worst plan could find records faster than
that, and if it were actually scanning everything sequentially, there
would be a fair amount of variation, say 25 seconds, 50 seconds, 100
seconds.  The most I have seen is a range of, say, 75-77.  That just
seems way too slow.

--
            ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
     Felix Finch: scarecrow repairman & rocket surgeon / felix@crowfix.com
  GPG = E987 4493 C860 246C 3B1E  6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: unique index on variable time
Next
From: "Thomas F. O'Connell"
Date:
Subject: ERROR: could not access status of transaction