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