Re: Any better plan for this query?..

Поиск
Список
Период
Сортировка
От Dimitri
Тема Re: Any better plan for this query?..
Дата
Msg-id 5482c80a0905060533y584f3096mdcb828734ba70ed@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Any better plan for this query?..  (Merlin Moncure <mmoncure@gmail.com>)
Ответы Re: Any better plan for this query?..  (Richard Huxton <dev@archonet.com>)
Список pgsql-performance
I'll try to answer all mails at once :-))

- query is running fully in RAM, no I/O, no network, only CPU time

- looping 100 times the same query gives 132ms total time (~1.32ms per
query), while it's 44ms on InnoDB (~0.44ms per query)

- disabling seq scan forcing a planner to use an index scan, and
finally it worse as gives 1.53ms per query..

- prepare the query helps: prepare statement takes 16ms, but execute
runs in 0.98ms  = which make me think it's not only a planner
overhead... And it's still 2 times lower vs 0.44ms.
Also, generally prepare cannot be used in this test case as we suppose
any query may be of any kind (even if it's not always true :-))

- char or varchar should be used here because the reference code is
supposed to accept any characters (alphanumeric)

- it also reminds me that probably there are some extra CPU time due
locale setting - but all my "lc_*" variables are set to "C"...

Rgds,
-Dimitri


On 5/6/09, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Wed, May 6, 2009 at 7:46 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
>> prepare history_stat(char(10) as
>
> typo:
> prepare history_stat(char(10)) as
>

В списке pgsql-performance по дате отправления:

Предыдущее
От: "Albe Laurenz"
Дата:
Сообщение: Re: Any better plan for this query?..
Следующее
От: Dimitri
Дата:
Сообщение: Re: Any better plan for this query?..