Re: proposal - log_full_scan - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: proposal - log_full_scan
Date
Msg-id 7BE7E917-78B4-423F-94C4-0691A4142B3E@yesql.se
Whole thread Raw
In response to Re: proposal - log_full_scan  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
> On 6 Jul 2021, at 18:14, Pavel Stehule <pavel.stehule@gmail.com> wrote:

> I thought about it more, and sometimes bitmap index scans are problematic too, index scans in nested loops can be a
problemtoo. 

Right.  Depending on the circumstances, pretty much anything in a plan can be
something deemed problematic in some production setting.

> Unfortunately, this idea is not well prepared. My patch was a proof concept - but I think so it is not a good start
point.Maybe it needs some tracing API on executor level and some tool like "perf top", but for executor. Post execution
analysisis not a good direction with big overhead, and mainly it is not friendly in critical situations. I need some
handytool like perf, but for executor nodes. I don't know how to do it effectively. 

These are hot codepaths so adding tracing instrumentation which collects enough
information to be useful, and which can be drained fast enough to not be a
resource problem is tricky.

> Thank you for your review and for your time, but I think it is better to remove this patch from commit fest. I have
noidea how to design this feature well :-/ 

No worries, I hope we see an updated approach at some time.  In the meantime
I'm marking this patch Returned with Feedback.

--
Daniel Gustafsson        https://vmware.com/




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: visibility map corruption
Next
From: Jim Mlodgenski
Date:
Subject: Re: Hook for extensible parsing.