Re: join removal

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
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-28 20:12:32
Message-ID: 4934.1269807152@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, Mar 28, 2010 at 2:10 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> joinremoval.c ?

> Maybe, except as I mentioned in the email linked upthread, my plan for
> implementing inner join removal would also include allowing join
> reordering in cases where we currently don't. So I don't want to
> sandbox it too tightly as join removal, per se, though that's
> certainly what we have on the table ATM. It's more like advanced
> open-heart join-tree surgery - like prepjointree, but much later in
> the process.

Hm. At this point we're not really working with a join *tree* in any
case --- the data structure we're mostly concerned with is the list of
SpecialJoinInfo structs, and what we're trying to do is weaken the
constraints described by that list. So I'd rather stay away from "tree"
terminology.

planjoins.c would fit with other names in the plan/ directory but it
seems like a misnomer because we're not really "planning" any joins
at this stage.

adjustjoins.c? loosenjoins.c? weakenjoins.c?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2010-03-28 20:40:01 Alpha release this week?
Previous Message Tom Lane 2010-03-28 20:01:57 Re: BUG #5394: invalid __declspec for PG_MODULE_MAGIC