Re: Gather performance analysis

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: Gather performance analysis
Дата
Msg-id 1196cd47-c247-10d8-dc73-d2fd84aee04c@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Gather performance analysis  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Gather performance analysis  (Robert Haas <robertmhaas@gmail.com>)
Re: Gather performance analysis  (Dilip Kumar <dilipbalaut@gmail.com>)
Список pgsql-hackers
On 9/23/21 9:31 PM, Robert Haas wrote:
> On Wed, Sep 8, 2021 at 2:06 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>> But I am attaching both the patches in case you want to play around.
> 
> I don't really see any reason not to commit 0001. Perhaps some very
> minor grammatical nitpicking is in order here, but apart from that I
> can't really see anything to criticize with this approach. It seems
> safe enough, it's not invasive in any way that matters, and we have
> benchmark results showing that it works well. If someone comes up with
> something even better, no harm done, we can always change it again.
> 
> Objections?

Yeah, it seems like a fairly clear win, according to the benchmarks.

I did find some suspicious behavior on the bigger box I have available 
(with 2x xeon e5-2620v3), see the attached spreadsheet. But it seems 
pretty weird because the worst affected case is with no parallel workers 
(so the queue changes should affect it). Not sure how to explain it, but 
the behavior seems consistent.

Anyway, the other machine with a single CPU seems perfectly clean.



regards


-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Вложения

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: OpenSSL 3.0.0 compatibility
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [PATCH] Allow queries in WHEN expression of FOR EACH STATEMENT triggers