Re: Gather performance analysis

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Gather performance analysis
Дата
Msg-id CA+TgmoY829B1KpY3w3PqdRRoDu7oGgt0i6N_N5JKKmL_Sddtbw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Gather performance analysis  (Dilip Kumar <dilipbalaut@gmail.com>)
Список pgsql-hackers
On Tue, Sep 28, 2021 at 2:49 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>                           16k             64k       256k        1024k
> Head               1232.779    804.24    1134.723    901.257
> Patch              1371.493    1277.705    862.598    783.481
>
> So what I have noticed is that in most of the cases on head as well as
> with the patch, increasing the queue size make it faster, but with
> head suddenly for this particular combination of rows, column and
> thread the execution time is very low for 64k queue size and then
> again the execution time increased with 256k queue size and then
> follow the pattern.  So this particular dip in the execution time on
> the head looks a bit suspicious to me.  I mean how could we justify
> this sudden big dip in execution time w.r.t the other pattern.

Oh, interesting. So there's not really a performance regression here
so much as that one particular case ran exceptionally fast on the
unpatched code.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



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

Предыдущее
От: Richard Yen
Дата:
Сообщение: Re: Patch to allow pg_filedump to support reading of pg_filenode.map
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: when the startup process doesn't (logging startup delays)