Re: Gather performance analysis - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: Gather performance analysis
Date
Msg-id 1196cd47-c247-10d8-dc73-d2fd84aee04c@enterprisedb.com
Whole thread Raw
In response to Re: Gather performance analysis  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Gather performance analysis  (Robert Haas <robertmhaas@gmail.com>)
Re: Gather performance analysis  (Dilip Kumar <dilipbalaut@gmail.com>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: OpenSSL 3.0.0 compatibility
Next
From: Robert Haas
Date:
Subject: Re: [PATCH] Allow queries in WHEN expression of FOR EACH STATEMENT triggers