Tom Lane <tgl@sss.pgh.pa.us> writes:
> Greg Stark <gsstark@mit.edu> writes:
>
> > How feasible would it be to have a btree index on ctid?
>
> Why would you want one? Direct access by ctid beats out an index lookup
> every time.
Of course. But as I mentioned, I have a cunning plan.
If you have two indexes (a,ctid) and (b,ctid) and do a query where a=1 and b=2
then it would be particularly easy to combine the two efficiently.
If specially marked btree indexes -- or even all btree indexes -- implicitly
had ctid as a final sort order after all the index column, then it would
esentially obviate the need for bitmap indexes. They wouldn't have the space
advantage, but they would be possible to combine using arbitrary boolean
expressions without looking at the actual tuples.
This is essentially what is in the TODO about using bitmaps, but without
having to do any extra sorts.
This would only really be an advantage for particularly wide tables where the
combination of boolean clauses narrows the result set down a lot more than any
one clause.
> In any case, vacuum and friends would break such an index entirely.
That was what I was afraid of.
--
greg