More than a year ago, I wrote in
http://archives.postgresql.org/message-id/14624.1283463...@sss.pgh.pa.us
Awhile back I ranted about replacing the planner's concept of inner
indexscans with a more generalized notion of parameterized paths:
On Wed, Nov 9, 2011 at 5:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
More than a year ago, I wrote in
http://archives.postgresql.org/message-id/14624.1283463...@sss.pgh.pa.us
Awhile back I ranted about replacing the planner's concept of inner
indexscans with a more generalized notion of
On Thu, Sep 2, 2010 at 5:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Awhile back I ranted about replacing the planner's concept of inner
indexscans with a more generalized notion of parameterized paths:
http://archives.postgresql.org/pgsql-hackers/2009-10/msg00994.php
The executor fixes for
Robert Haas robertmh...@gmail.com writes:
On Thu, Sep 2, 2010 at 5:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The best idea I can come up with at the moment is to compute best case
and worst case costs for a parameterized path,
Interestingly, I previously proposed almost exactly this approach
On Fri, Sep 3, 2010 at 2:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
On reflection I think that for parameterized paths the problem won't be
too bad, because (a) we'll ignore parameterized paths except when
considering a join to the right outer rel, so their presence in the
rel's pathlist won't
Robert Haas robertmh...@gmail.com writes:
On Fri, Sep 3, 2010 at 2:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
On reflection I think that for parameterized paths the problem won't be
too bad, because (a) we'll ignore parameterized paths except when
considering a join to the right outer rel, so
On Fri, Sep 3, 2010 at 5:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Sep 3, 2010 at 2:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
On reflection I think that for parameterized paths the problem won't be
too bad, because (a) we'll ignore
