Re: Question about indexes

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Question about indexes
Date: 2004-01-27 23:11:31
Message-ID: 87d695t2ak.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Greg Stark <gsstark(at)mit(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Pflug 2004-01-27 23:16:51 Re: Write cache
Previous Message Tom Lane 2004-01-27 22:51:56 Re: Question about indexes