Re: proposal - log_full_scan

Поиск
Список
Период
Сортировка
От Daniel Gustafsson
Тема Re: proposal - log_full_scan
Дата
Msg-id 7BE7E917-78B4-423F-94C4-0691A4142B3E@yesql.se
обсуждение исходный текст
Ответ на Re: proposal - log_full_scan  (Pavel Stehule <pavel.stehule@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: visibility map corruption
Следующее
От: Jim Mlodgenski
Дата:
Сообщение: Re: Hook for extensible parsing.