| От | torikoshia |
|---|---|
| Тема | Re: RFC: Logging plan of the running query |
| Дата | |
| Msg-id | ac6c51071316279bf903078cf264c37a@oss.nttdata.com обсуждение исходный текст |
| Ответ на | Re: RFC: Logging plan of the running query (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: RFC: Logging plan of the running query
Re: RFC: Logging plan of the running query |
| Список | pgsql-hackers |
On Fri, Feb 16, 2024 at 11:42 PM torikoshia <torikoshia@oss.nttdata.com> wrote: > I'm not so sure about the implementation now, i.e. finding the next > node > to be executed from the planstate tree, but I'm going to try this > approach. Attached a patch which takes this approach. - I saw no way to find the next node to be executed from the planstate tree, so the patch wraps all the ExecProcNode of the planstate tree at CHECK_FOR_INTERRUPTS(). - To prevent overhead of this wrapped function call, unwrap it at the end of EXPLAIN code execution. - I first tried to use ExecSetExecProcNode() for wrapping, but it 'changes' ExecProcNodeMtd of nodes, not 'adds' some process to ExecProcNodeMtd. I'm not sure this is the right approach, but attached patch adds new member ExecProcNodeOriginal to PlanState to preserve original ExecProcNodeMtd. Any comments are welcomed. -- Regards, -- Atsushi Torikoshi NTT DATA Group Corporation
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера