Re: Partitioning feature ... - Mailing list pgsql-hackers

From Kedar Potdar
Subject Re: Partitioning feature ...
Date
Msg-id bd8134a40903240516g51aa23e5g84226de7d5e6066c@mail.gmail.com
Whole thread Raw
In response to Re: Partitioning feature ...  (Nikhil Sontakke <nikhil.sontakke@enterprisedb.com>)
List pgsql-hackers
Hi Nikhil,

Update operation is performed as a combination of 'delete' and 'insert'.

In Update trigger, the row is deleted from relation according to it's 'ctid'. A look-up on system catalog for partitions is performed to identify the target table by evaluating values of partition-key attributes, of the given row. The constraints of this target table are evaluated for this new row and if found valid, the row is inserted.

Regards,
--
Kedar.



On Mon, Mar 23, 2009 at 5:09 PM, Nikhil Sontakke <nikhil.sontakke@enterprisedb.com> wrote:
Hi Kedar, 


The syntax used conforms to most of the suggestions mentioned in http://archives.postgresql.org/pgsql-hackers/2008-01/msg00413.php, barring the following:
-- Specification of partition names is optional. System will be able to generate partition names in such cases.
-- Sub partitioning

I was wondering if there is a need to mention the type of partition while dropping it. 

E.g 
ALTER table x DROP RANGE PARTITION x_part;

The type of partition (RANGE, HASH) could be dropped according to me.
 

We are maintaining a system catalog(pg_partition) for partition meta-data. System will look-up this table to find appropriate partition to operate on.
System internally uses low-level 'C' triggers to row-movement.

Can you elaborate more on how do you handle updates with these triggers?

Regards,
Nikhils
-- 
http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Zdenek Kotala
Date:
Subject: Re: cs_CZ vs regression tests, part N+1
Next
From: Peter Eisentraut
Date:
Subject: Re: Sampling Profler for Postgres