Heikki Linnakangas <hlinnaka@iki.fi> writes:
> Hmm, so return the computed column from the index instead of recomputing
> it? Yeah, that makes sense too and would help in this example.
Yeah, that's been on the to-do list for ages. The main problems are
(1) we need the planner to not spend too much effort on looking for
subexpression matches, and (2) amcanreturn ability isn't implemented
by the executor in plain indexscans. There's another thread right now
discussing fixing (2), after which we could perhaps work on this.
> It won't
> help in all cases though, the index might not store the original value
> in the first place.
I'm a little skeptical that an index could produce an accurate ORDER BY
result if it doesn't store the values-to-be-sorted exactly. Any loss
of information would compromise its ability to sort nearly-identical
values correctly. A more credible argument is that the index might
expose amcanorder ability but not amcanreturn; but what I'm saying is
that that's probably an AM implementation gap that ought to be fixed.
How much of your patchset still makes sense if we assume that we
can always extract the ORDER BY column values from the index?
regards, tom lane
