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@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
