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

> > 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

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

On 2018-05-26 17:08:51 -0400, Robert Haas wrote: > On Fri, May 25, 2018 at 2:40 AM, Andres Freund wrote: > > 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. > > Some of

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

On Fri, May 25, 2018 at 2:40 AM, Andres Freund wrote: > 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. Some of that is because this format is intrinsically hard to read, but

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

On 05/24/2018 11:26 PM, Heikki Linnakangas wrote: > Cool stuff! > > On 25/05/18 06:35, Andres Freund wrote: >> For example, this converts this converts TPCH's Q01: +1 Wicked cool! -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open

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

Hi, On 2018-05-25 09:26:47 +0300, Heikki Linnakangas wrote: > Cool stuff! Thanks! > On 25/05/18 06:35, Andres Freund wrote: > > For example, this converts this converts TPCH's Q01: > > > > tpch_1[26142][1]=# SET client_min_messages ='log'; > > tpch_1[26142][1]=# SELECT > > l_returnflag, >

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

Cool stuff! On 25/05/18 06:35, Andres Freund wrote: For example, this converts this converts TPCH's Q01: tpch_1[26142][1]=# SET client_min_messages ='log'; tpch_1[26142][1]=# SELECT l_returnflag, l_linestatus, sum(l_quantity) AS sum_qty, sum(l_extendedprice) AS

Redesigning the executor (async, JIT, memory efficiency)

Hi, The current executor structure limits us in a number of ways that are becoming problematic. I'll outline in this email how I think we should rework it. Including a prototype for the first, most drastic, steps. The primary problems with the current design that I want to address are: 1)