From: | felix(at)crowfix(dot)com |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Query runs fast or slow |
Date: | 2006-04-17 02:47:23 |
Message-ID: | 20060417024723.GA6234@crowfix.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)crowfix(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas F. O'Connell | 2006-04-17 06:26:03 | ERROR: could not access status of transaction |
Previous Message | Robert Treat | 2006-04-16 23:06:33 | Re: Google Summer of Code (Fix aggregate operators & Implement features such as Data Cubes and Skyline) |