Re: Gather performance analysis

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Gather performance analysis
Date: 2021-09-23 20:00:02
Message-ID: 1196cd47-c247-10d8-dc73-d2fd84aee04c@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/23/21 9:31 PM, Robert Haas wrote:
> On Wed, Sep 8, 2021 at 2:06 AM Dilip Kumar <dilipbalaut(at)gmail(dot)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 Content-Type Size
queue-results.ods application/vnd.oasis.opendocument.spreadsheet 32.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2021-09-23 20:02:38 Re: [PATCH] Allow queries in WHEN expression of FOR EACH STATEMENT triggers
Previous Message Robert Haas 2021-09-23 19:54:54 Re: OpenSSL 3.0.0 compatibility