Thanks! I've been waiting for this.
At Thu, 24 May 2018 20:35:39 -0700, Andres Freund wrote in
<20180525033538.6ypfwcqcxce6z...@alap3.anarazel.de>
> 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
> r
>
> 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 diff
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 that is because this for
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
it's also partly beca
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 So
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,
> >
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 s
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) Exec
