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 for
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
On Tue, Sep 15, 2009 at 7:53 AM, Robert Haas robertmh...@gmail.com 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
On Mon, Sep 14, 2009 at 5:41 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Tue, Sep 15, 2009 at 5:47 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Mon, Sep 14, 2009 at 5:41 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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
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 add
