From: | Douglas Doole <dougdoole(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)postgresql(dot)org, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Subject: | Re: Redesigning the executor (async, JIT, memory efficiency) |
Date: | 2018-05-27 14:49:03 |
Message-ID: | CADE5jYL=BhHq7t91SjJfn4Kr-PR5M_x9L2BiArLcKupb1-OG7A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Rofail | 2018-05-27 15:31:51 | Re: [HACKERS] GSoC 2017: Foreign Key Arrays |
Previous Message | Andrew Dunstan | 2018-05-27 12:45:50 | Re: perlcritic and perltidy |