From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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 15:16:59 |
Message-ID: | 20150306151659.GP29780@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* 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.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2015-03-06 15:30:08 | Re: MD5 authentication needs help |
Previous Message | Robert Haas | 2015-03-06 15:16:12 | Re: parallel mode and parallel contexts |