On Wed, Nov 9, 2011 at 5:12 PM, Tom Lane 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 "parameterized path
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":
> http://archives.postgresql.org/pgsql-hackers/2009-
On Fri, Sep 3, 2010 at 5:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Sep 3, 2010 at 2:04 PM, Tom Lane 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
Robert Haas writes:
> On Fri, Sep 3, 2010 at 2:04 PM, Tom Lane 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 pat
On Fri, Sep 3, 2010 at 2:04 PM, Tom Lane 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 cost much other
Robert Haas writes:
> On Thu, Sep 2, 2010 at 5:31 PM, Tom Lane 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 to
> handle a couple of other
On Thu, Sep 2, 2010 at 5:31 PM, Tom Lane 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 that are done,
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 that are done, and now I'm grappling with getting
the planner to do somet
