Re: Query runs fast or slow

Поиск
Список
Период
Сортировка
От felix@crowfix.com
Тема Re: Query runs fast or slow
Дата
Msg-id 20060417024723.GA6234@crowfix.com
обсуждение исходный текст
Ответ на Re: Query runs fast or slow  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: unique index on variable time
Следующее
От: "Thomas F. O'Connell"
Дата:
Сообщение: ERROR: could not access status of transaction