Re: Table inheritance implementation.

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Grzegorz Nowakowski <krecik(at)e-wro(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org
Subject: Re: Table inheritance implementation.
Date: 2007-01-05 09:55:06
Message-ID: 20070105095506.GA27598@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Jan 05, 2007 at 09:27:31AM +0100, Grzegorz Nowakowski wrote:
> Well, I never used partitioning and I don't know what it's worth but
> just after sending my original mail I got another variant of the idea:
> to duplicate columns (parent(p), child(p,c)), so inserts into child
> update both parent's and child's index. This way we trade space (common
> columns are replicated along inheritance hierarchy) and some speed
> (inserts into child are slower because they also have to update parent)
> for some other speed (selects work without join penalty). Yet still we
> have the primary benefit: parent's constraints and indexes work as
> expected.

One of the reasons it hasn't happened yet is related to locking of
indexes. It is currently assumed that if you lock a table, you've
locked all the indexes implicitly. If you have an index that can be
updated by multiple tables, what are the locking semantics then? If you
want to drop the parent index, do you have to lock every child table?

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Grzegorz Nowakowski 2007-01-05 10:25:56 Re: Table inheritance implementation.
Previous Message JTyrrell 2007-01-05 09:16:14 Re: pg_dump problems