| 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: | Whole Thread | Raw Message | 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 |