Heikki Linnakangas <heikki@enterprisedb.com> writes:
> Alvaro Herrera wrote:
>> At this
>> point I feel like the patch still needs some work and reshuffling before
>> it is in an acceptable state. The fact that there are some API changes
>> for which the patch needs to be adjusted makes me feel like we should
>> put this patch on hold for 8.4. So we would first get the API changes
>> discussed and done and then adapt this patch to them.
> I hate to say it but I agree.
I concur with putting this whole area off till 8.4. We do not have any
consensus on what the API should be, which is exactly why the patch was
never finished. All the proposals are pretty ugly.
Another problem: frankly I'm pretty dissatisfied with the entire concept
of not storing all the index keys, especially in the proposed way which
would eliminate any outside control over whether keys are dropped or
not. Two problems I can see with it are:
1. The performance hit for functional indexes could be really steep,
since you'd need to recompute a potentially expensive function to
recheck matches.
2. This would forever cut off any development of indexscans that make
use of index key data beyond what btree itself knows how to do. An
example of the sort of thing I'm thinking about is applying a LIKE or
regex pattern match operator against the index key before visiting the
heap --- not just a derived >= or <= condition, but the actual pattern
match. We've discussed adding an index AM call that returns the key
values, which'd allow the executor to apply non-btree operators to them
before visiting the heap. But that idea is DOA if the planner can't
tell in advance whether the entries will be available.
So instead of pressing to try to get something into 8.3, I would rather
we stand back and think about it some more.
regards, tom lane
