Re: Inheritance

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Cc: "Bruce Momjian" <pgman@candle.pha.pa.us>, "Curt Sampson" <cjs@cynic.net>, "Don Baccus" <dhogaza@pacifier.com>, "Lamar Owen" <lamar.owen@wgcr.org>, "Greg Copeland" <greg@CopelandConsulting.Net>, "PostgresSQL Hackers Mailing List" <pgsql-hackers@postgresql.org>
Date: 2002-08-14T13:59:15Z
Lists: pgsql-hackers
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Is it theoretically possible to add support to btree for storing table along
> with the indexed value?

That's what we need, all right.

> This would obviously add overhead, so it would only
> be done for spanning indexes.  The index would also take up more space on
> disk I guess.
> When a new inherited table is created, all parent indices would be dropped
> and recreated as spanning indices and vice versa.

Seems like the hard way.  Instead use a t_infomask bit in indextuples to
indicate that the index entry points to a table other than the one its
index is nominally associated with; if and only if this bit is set, the
table OID follows the indextuple header.  This way, you don't have to
reindex just to create a child table, and you also don't pay any extra
space cost for index entries that in fact point at the parent.

There are a veritable ton of other issues to be resolved --- like how do
we (efficiently) find all the indexes relevant to a given child table
--- but the physical storage doesn't seem too complicated.

			regards, tom lane