Re: Inherited indexes.

On Tue, Oct 04, 2005 at 11:05:49AM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jnasby@pervasive.com> writes:
> > On Sun, Oct 02, 2005 at 09:46:07PM -0400, Tom Lane wrote:
> >> 1. A cross-table index would need to store a table OID as well as the
> >> existing block/offset information in order to tell you what an entry is
> >> pointing at.
> 
> > Wouldn't it make more sense to use a smaller pointer to a table of OIDs
> > that that index covers?
> 
> Smaller than what?  Don't tell me you want to restrict how many tables a
> cross-table index can handle :-(
> 
> In any case, the gain from doing that would be exactly zero because of
> alignment considerations: the size of an index tuple header really has
> to be a multiple of MAXALIGN.

Hrm, I see that IndexTupleData doesn't have room 'left over' like
HeapTupleData does. If it did, it would probably be a win to allow for
indexes that are on less than X number of tables, where X is whatever
value we can fit into the tuple header. Since this could be exceeded at
any time, we'd also need a flag to indicate that a given tuple is for a
table that's not in the lookup table and that an actual OID is stored.

Given that that's not (currently) the case, it seems that the unused bit
could be used to indicate if the tuple was for a table other than the
one the index was originally created on. That would allow for adding a
table to an existing index without re-writing the entire thing. It could
also provide some speed improvement in cases where the table the index
was defined on contained the majority of the data, but that's a pretty
far-out corner case.

Of course, this is all academic performance tuning until we actually
have cross-table indexes.

Does that 'just' leave locking as the issue? I think cross-table indexes
are going to become a lot more important as our partitioning support
increases, so it would be good if this could get done for 8.2 (I think
it's on Simon's list right now).
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461