On Mon, Sep 27, 2010 at 5:09 PM, Daniel Grace <dgr...@wingsnw.com> wrote: > Is there any chance this might be looked at in a future release?
This is another interesting example of a case where an inlining-type optimization (which is effectively what's happening here, I think) turns out to be a negative. We had one a while back that involved actual function inlining, which is not quite what's happening here, but it's close. It doesn't seem too hard to figure out whether or not inlining is a win (non-trivial subexpressions should probably never get duplicated), but nobody's gotten around to writing the logic to make it work yet. One useful technique is to stick "OFFSET 0" into the subquery; that prevents it from being inlined and gives you something more like the plan you were hoping for. Whether or not this will get looked at in a future release is a tough question to answer. It's possible that someone (most likely, Tom) will get motivated to fix this out of sheer annoyance with the current behavior, or will notice a way to improve it incidentally while making some other change. But of course the only way to make sure it gets fixed is to do it yourself (or pay someone to do it). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
