Skip site navigation (1) Skip section navigation (2)

Re: Question about indexes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Question about indexes
Date: 2004-01-27 23:24:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Greg Stark <gsstark(at)mit(dot)edu> writes:
> 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.

I don't think so.  You are thinking only of exact-equality queries ---
as soon as the WHERE clause describes a range of index entries, the
readout wouldn't be sorted by ctid anyway.

Combining indexes via a bitmap intermediate step (which is not really
the same thing as bitmap indexes, IIUC) seems like a more robust
approach than relying on the index entries to be in ctid order.

But if we did want to sort indexes that way, we could do it today,
I think.  The ctid is already stored in index entries (it is the
"payload" remember...) and we could use it as a tiebreaker when
determining insertion position.  This doesn't have the problems that
putting ctid into the user columns would do, because the system knows
about that ctid as being special; the difficulty with ctid in the user
columns is the code not knowing that it'd need to change on a tuple move.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: James William PyeDate: 2004-01-27 23:35:33
Subject: Re: pl/pgSQL versus pl/Python
Previous:From: Andreas PflugDate: 2004-01-27 23:16:51
Subject: Re: Write cache

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group