Is this a TODO?
---
Heikki Linnakangas wrote:
> Robert Haas wrote:
> > Since you previously stated that you were going to put this patch
> > aside to work on HS and SR[1], I'm going to move this to Returned with
> > Feedback
Robert Haas wrote:
> Since you previously stated that you were going to put this patch
> aside to work on HS and SR[1], I'm going to move this to Returned with
> Feedback for now. Hope that's OK, and that the feedback is sufficient
> and useful.
Yes, on both counts. Thank you!
--
Heikki Linna
On Mon, Sep 14, 2009 at 5:41 AM, Heikki Linnakangas
wrote:
> Heikki Linnakangas wrote:
>> Tom Lane wrote:
>>> It strikes me that in the cases where it wouldn't be necessary to
>>> compute junk sort-key columns, it would be because we were scanning an
>>> index that includes those values. So if th
On Tue, Sep 15, 2009 at 7:53 AM, Robert Haas wrote:
>>> Consider A IJ B, with
>>> the scan over A implemented as an index scan. It seems to me that if
>>> the join selectivity is < 1, then assuming there's a choice, we
>>> probably want to join A to B and then do the heap fetches against A
>>> a
On Tue, Sep 15, 2009 at 5:47 AM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>> Hi, I'm reviewing this patch for the 2009-09 CommitFest.
>
> Thank you!
>
>> It doesn't seem to compile.
>
> Looks like the patch has bitrotted, sorry about that. Attached is an
> updated version. I've also pushed t
On Mon, Sep 14, 2009 at 5:41 AM, Heikki Linnakangas
wrote:
> Heikki Linnakangas wrote:
>> Tom Lane wrote:
>>> It strikes me that in the cases where it wouldn't be necessary to
>>> compute junk sort-key columns, it would be because we were scanning an
>>> index that includes those values. So if th
Tom Lane wrote:
> It strikes me that in the cases where it wouldn't be necessary to
> compute junk sort-key columns, it would be because we were scanning an
> index that includes those values. So if the plan were set up to pull
> those values from the index and return them, then we'd not have to a
I've been looking at bug #5000 (must be some kind of milestone), in
which the complaint was that the planner won't use an indexscan on a
functional index to satisfy an ORDER BY. Of course it *can* do that,
it's just not being very bright about it. Consider the following
example in the regression
