Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a
Date
Msg-id 603c8f070912031951w66c45272l3de6d5d04f84278e@mail.gmail.com
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Rewrite GEQO's gimme_tree function so that it always finds a  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Dec 2, 2009 at 10:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Well, when I was testing, I believe I observed that an n-way join with
>> 1 cross join was slower to plan than an n-way join with no cross
>> joins.  ISTM that it should actually be faster, because you should
>> plan it like an (n-1)-way join and then do the cross join at the end.
>
> It's not entirely clear to me what case you're describing, but I wonder
> whether this was a "flat" join problem or restricted by the collapse
> limits.

Argh.  I can't reproduce exactly what I thought I was seeing before.
However, with the attached schema, geqo off, and the collapse
thresholds set to 100, "explain select * from bar2_view" and "explain
select * from bar3_view" have roughly the same run time.  They are
identical except that one of the join clauses has been omitted in the
second case.  One would think that the second case could be planned
faster, if we plan to just leave the cross join to the end.

(And in fact on my system if you remove bar8 from the second view
entirely the plan time improves by a factor of six.)

...Robert

Attachment

pgsql-hackers by date:

Previous
From: KaiGai Kohei
Date:
Subject: Re: [PATCH] Largeobject Access Controls (r2432)
Next
From: "David E. Wheeler"
Date:
Subject: Re: operator exclusion constraints