Re: Auto creation of Partitions

From: "Joris Dobbelsteen" <Joris(at)familiedobbelsteen(dot)nl>
To: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "NikhilS" <nikkhils(at)gmail(dot)com>
Cc: "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Auto creation of Partitions
Date: 2007-03-07 20:13:40
Message-ID: 73427AD314CC364C8DF0FFF9C4D693FF0379C6@nehemiah.joris2k.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

>-----Original Message-----
>From: pgsql-hackers-owner(at)postgresql(dot)org
>[mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Alvaro Herrera
>Sent: woensdag 7 maart 2007 15:59
>To: NikhilS
>Cc: Zeugswetter Andreas ADI SD; Peter Eisentraut;
>pgsql-hackers(at)postgresql(dot)org
>Subject: Re: [HACKERS] Auto creation of Partitions
>
>I am wondering if we can implement unique indexes across
>several tables (inheritance hierarchy) not by using a single,
>big index covering all the tables, but rather by inserting a
>dummy entry into each partition's unique index.

I think that one big index is much better in this case. You are already
replicating the data and need a lot of work when updating the partition
structure (e.g. removing one).

[snip]

Rather:
If we have the partition relations (aka partition), then we can define a
unique index on it. This guarentees that there is at most one tuple with
the same value (for the specified columns) for every individual
partition.

Now for the inserts.
We already guarentee that is unique within the partition it lives. So we
must insert it first.
Next its to check the other partitions (in order!) for existence of a
row with a similar context. Of course we require full visibility of the
data.
We do the insert first, as this ensures other will find it. The order is
also important, otherwise there can be situations where we can't
guarentee the constraint.

Updates are exactly the same.
Deletes are trivial.

Perhaps you can do it without an index, but this is nothing different
than for a normal table.

- Joris Dobbelsteen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2007-03-07 21:31:25 Re: Synchronized Scan update
Previous Message Tom Lane 2007-03-07 20:09:13 Re: Bug in VACUUM FULL ?

Browse pgsql-patches by date

  From Date Subject
Next Message Tatsuhito Kasahara 2007-03-08 03:26:43 Patch for pgstatindex to fix a bug reporting a value of strange leaf_fragmentation
Previous Message Zeugswetter Andreas ADI SD 2007-03-07 16:45:51 Re: Auto creation of Partitions