Re: Redesigning the executor (async, JIT, memory efficiency)

Поиск
Список
Период
Сортировка
От Douglas Doole
Тема Re: Redesigning the executor (async, JIT, memory efficiency)
Дата
Msg-id CADE5jYL=BhHq7t91SjJfn4Kr-PR5M_x9L2BiArLcKupb1-OG7A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Redesigning the executor (async, JIT, memory efficiency)  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
I think we're going to have to continue showing the tree plan. I think
the linear version is far too hard to understand for anything
nontrivial. 

Hey Andres, what you're pitching here is very similar to the way DB2 works. It actually has two different explain tools that dumps the two different formats. The tree dump is the preferred format, but there are times where the human-readable dump of the executor steps is very useful. Particularly, as mentioned elsewhere in this thread, when the executor steps diverge from the plan.

One thing that helps correlate the two formats is that each node in the tree dump is numbered and each step in the executor is annotated with the corresponding tree node number.

Another tool that was invaluable is a readable dump (effectively a disassembly) of the byte code. It was only useful to developers, but when something goes wrong in the executor it was incredibly useful to see exactly what the byte code was specifying (as opposed the human readable format of explain, which could hide subtle details.)

- Doug
Salesforce

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: perlcritic and perltidy
Следующее
От: Mark Rofail
Дата:
Сообщение: Re: [HACKERS] GSoC 2017: Foreign Key Arrays