Re: Redesigning the executor (async, JIT, memory efficiency) - Mailing list pgsql-hackers

From Douglas Doole
Subject Re: Redesigning the executor (async, JIT, memory efficiency)
Date
Msg-id CADE5jYL=BhHq7t91SjJfn4Kr-PR5M_x9L2BiArLcKupb1-OG7A@mail.gmail.com
Whole thread Raw
In response to Re: Redesigning the executor (async, JIT, memory efficiency)  (Andres Freund <andres@anarazel.de>)
List 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 by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: perlcritic and perltidy
Next
From: Mark Rofail
Date:
Subject: Re: [HACKERS] GSoC 2017: Foreign Key Arrays