Skip site navigation (1) Skip section navigation (2)

Re: join removal

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <stark(at)mit(dot)edu>, "<pgsql-hackers(at)postgresql(dot)org>" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: join removal
Date: 2010-03-27 11:13:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Mar 26, 2010 at 6:10 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Reading through the "optimizer functions" section of
>> src/backend/optimizer/README, it seems like the earliest point at
>> which we could do this would be just before the call to
>> make_one_rel().  I think that would eliminate some redundant
>> computation.
> Maybe.  It would also add a new pass over the join tree that, in
> 99% of cases, would make no useful contribution whatever.  It's
> possible that this would still be cheaper than a lot of failed calls
> to join_is_removable, but I'm unconvinced --- we were able to make
> the failure path through that pretty durn cheap for most simple cases.
> The approach you're sketching still involves a combinatorial search
> so I doubt it's going to be cheap.

I'm not totally sure about this but I think it's possible to do this
without a combinatorial search.  Suppose we just iterate over the list
SpecialJoinInfo structures and look for those where jointype is LEFT,
delay_upper_joins is false, and min_righthand is a singleton; and then
consider the removability of a join between min_lefthand and
min_righthand.  I might be missing a case, but I think whatever answer
we get from that calculation is the answer, period.  Adding more
relations to the LHS won't change anything.

> Yeah.  I had been thinking that we could build the RelOptInfo and
> IndexOptInfo structs earlier, but really all of the
> clause-classification work done by deconstruct_jointree is important
> as well for this function's purposes, so it's not that easy to push
> back to prepjointree :-(.  I suspect that any such attempt would end
> up requiring a massive rethinking of the order of operations in the
> planner.  Maybe we should do that sometime but I'm not eager for it.

Agree.  If we ever do that, one of the things to think about is
minimizing memory consumption...


In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2010-03-27 11:34:30
Subject: Re: changes to documentation build
Previous:From: Simon RiggsDate: 2010-03-27 10:10:42
Subject: Re: Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group