Re: [Commitfest 2022-07] Patch Triage: Needs Review, Part 1 - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: [Commitfest 2022-07] Patch Triage: Needs Review, Part 1
Date
Msg-id 20220729063813.i2y7qoyf4izdv3va@jrouhaud
Whole thread Raw
In response to [Commitfest 2022-07] Patch Triage: Needs Review, Part 1  (Jacob Champion <jchampion@timescale.com>)
Responses Re: [Commitfest 2022-07] Patch Triage: Needs Review, Part 1
List pgsql-hackers
Hi,

On Thu, Jul 28, 2022 at 02:28:23PM -0700, Jacob Champion wrote:
>
> = Stalled Patches, Need Help =
> [...]
> - Add extra statistics to explain for Nested Loop
>   https://commitfest.postgresql.org/38/2765/
>
> I think the author is hoping for help with testing and performance
> characterization.

As I mentioned in [1], this patch breaks the current assumption that
INSTRUMENT_ALL will lead to statement-level metrics that are generally useful.
According to the benchmark, the proposed patch would add a 1.5% overhead for
pg_stat_statements or any other similar extension that relies on INSTRUMENT_ALL
for no additional information, and I don't think it's acceptable.

I'm still not sure of what is the best way to fix that, but clearly something
has to be done, ideally without requiring every single pg_stat_statements-like
extension to be modified.

> The following are actively being worked and I expect to move them to
> next CF:
>
> - session variables, LET command

Yes please.



pgsql-hackers by date:

Previous
From: Nikita Malakhov
Date:
Subject: Re: Pluggable toaster
Next
From: Amit Kapila
Date:
Subject: Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns