From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, David Fetter <david(at)fetter(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: LATERAL |
Date: | 2009-12-18 03:13:34 |
Message-ID: | 603c8f070912171913m238023b4k2c80a709f0fb4a23@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Oct 18, 2009 at 2:57 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> You could probably convince me that a merge join is not going to be
>> too useful (how often can you want a merge join on the inner side of a
>> nested loop?
>
> Why not? As Andrew pointed out, what we're really trying to accomplish
> here is consider sub-join plans that are parameterized by a value
> obtained from an outer relation. I think we shouldn't artificially
> limit what we consider.
>
> But anyway I think we're on the same page here: what we ought to do is
> try implementing this scheme without any extra restrictions on what it
> considers, and see what the performance is like. We can try to limit
> what it considers if it turns out not to work well in the simplest
> form.
You mention what "we" ought to do here, so - is this something that
you're planning to have a go at?
Another question I have - while generalizing the inner-indexscan
machinery is an interesting join optimization technique, I'm thinking
that it actually has very little to do with LATERAL. Is there any
reason to suppose that one or the other needs to be done first?
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2009-12-18 03:14:49 | Re: [PATCH] remove redundant ownership checks |
Previous Message | Stephen Frost | 2009-12-18 03:09:31 | Re: [PATCH] remove redundant ownership checks |