From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Curt Sampson" <cjs(at)cynic(dot)net>, "Don Baccus" <dhogaza(at)pacifier(dot)com>, "Lamar Owen" <lamar(dot)owen(at)wgcr(dot)org>, "Greg Copeland" <greg(at)CopelandConsulting(dot)Net>, "PostgresSQL Hackers Mailing List" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Inheritance |
Date: | 2002-08-14 13:59:15 |
Message-ID: | 7694.1029333555@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2002-08-14 14:08:12 | Re: Open 7.3 items |
Previous Message | ngpg | 2002-08-14 13:46:59 | Re: Open 7.3 items |