From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Clamping reulst row number of joins. |
Date: | 2015-03-06 16:48:40 |
Message-ID: | 21674.1425660520@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> BTW, is that JOIN (VALUES(...)) thing common in applications, or did you
>> just use it to make a compact example? If it were something worth
>> optimizing, it seems like we could teach the planner to "pull up VALUES"
>> in the same way that it flattens sub-selects. I'm not sure if this is
>> worth the trouble or not, though.
> I've certainly seen and used values() constructs in joins for a variety
> of reasons and I do think it'd be worthwhile for the planner to know how
> to pull up a VALUES construct.
> Would that be a lot of effort, either code-wise or runtime-wise? My gut
> feeling is that it wouldn't be, but you're clearly in a much better
> position to determine that.
My guess is that it'd be pretty simple to do if we want to do it.
I've not looked at the code yet though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-03-06 16:58:42 | Re: Weirdly pesimistic estimates in optimizer |
Previous Message | Stephen Frost | 2015-03-06 16:19:04 | Re: MD5 authentication needs help |