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

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

In response to

Browse pgsql-hackers by date

  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