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.
On Mon, Mar 23, 2009 at 5:09 PM, Nikhil Sontakke <
> Hi Kedar,
>> The syntax used conforms to most of the suggestions mentioned in
>> 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.
> 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?
In response to
pgsql-hackers by date
|Next:||From: Peter Eisentraut||Date: 2009-03-24 12:16:55|
|Subject: Re: Sampling Profler for Postgres|
|Previous:||From: Zdenek Kotala||Date: 2009-03-24 11:23:56|
|Subject: Re: cs_CZ vs regression tests, part N+1|