Re: [GENERAL] Primary Key Increment Doesn't Seem Correct Under Table Partition

2010-01-29 Thread Alban Hertroys
On 29 Jan 2010, at 1:56, Yan Cheng Cheok wrote: > Isn't the primary constraint will implicitly create an index for day already? > > PRIMARY KEY (advertiser_id, day), Yes, but it's not a very efficient index to look for values of day if you don't provide a value for advertiser_id as well. See

Re: [GENERAL] Primary Key Increment Doesn't Seem Correct Under Table Partition

2010-01-28 Thread Yan Cheng Cheok
Sorry. I didn't get all your points. "defining a primary key constraint implicitly creates an index" - Yup. I agree on this. But what is the purpose, for author to explicitly define index for day? CREATE INDEX impressions_by_day_y2012m3ms2_day ON impressions_by_day_y2012m3ms2 (day); Isn't the

Re: [GENERAL] Primary Key Increment Doesn't Seem Correct Under Table Partition

2010-01-28 Thread Alban Hertroys
On 28 Jan 2010, at 2:10, Yan Cheng Cheok wrote: >>> EXECUTE 'CREATE TABLE ' || >> quote_ident(measurement_table_name) || ' >>> ( >>> CONSTRAINT >> pk_measurement_id_' || measurement_table_index || ' PRIMARY >> KEY (measurement_id), >>> CONSTRAINT >> fk_unit_id_'

Re: [GENERAL] Primary Key Increment Doesn't Seem Correct Under Table Partition

2010-01-27 Thread Yan Cheng Cheok
Thanks and Regards Yan Cheng CHEOK --- On Thu, 1/28/10, Alban Hertroys wrote: > From: Alban Hertroys > Subject: Re: [GENERAL] Primary Key Increment Doesn't Seem Correct Under Table > Partition > To: "Yan Cheng Cheok" > Cc: pgsql-general@postgresql.org > Da

Re: [GENERAL] Primary Key Increment Doesn't Seem Correct Under Table Partition

2010-01-27 Thread Alban Hertroys
On 27 Jan 2010, at 4:22, Yan Cheng Cheok wrote: > Hello all, > > I solve my problem using the following. It seems that when inherit from > parent table, the parent table's constraint is not being carried over to > child table. > > CREATE OR REPLACE FUNCTION measurement_insert_trigger() > RETUR

Re: [GENERAL] Primary Key Increment Doesn't Seem Correct Under Table Partition

2010-01-27 Thread Alban Hertroys
On 27 Jan 2010, at 2:00, Yan Cheng Cheok wrote: >>> However, whenever I insert row into measurement table, >> I realize its primary key value is going from 2, 4, 6, 8, >> 10... >>> >>> May I know how can I prevent this? >> >> Apparently nextval on that sequence gets called multiple >> times in yo

Re: [GENERAL] Primary Key Increment Doesn't Seem Correct Under Table Partition

2010-01-26 Thread Yan Cheng Cheok
Hello all, I solve my problem using the following. It seems that when inherit from parent table, the parent table's constraint is not being carried over to child table. CREATE OR REPLACE FUNCTION measurement_insert_trigger() RETURNS TRIGGER AS $BODY$DECLARE measurement_table_index bigint;

Re: [GENERAL] Primary Key Increment Doesn't Seem Correct Under Table Partition

2010-01-26 Thread Yan Cheng Cheok
Thanks and Regards Yan Cheng CHEOK --- On Tue, 1/26/10, Alban Hertroys wrote: > From: Alban Hertroys > Subject: Re: [GENERAL] Primary Key Increment Doesn't Seem Correct Under Table > Partition > To: "Yan Cheng Cheok" > Cc: pgsql-general@postgresql.org > D

Re: [GENERAL] Primary Key Increment Doesn't Seem Correct Under Table Partition

2010-01-26 Thread Alban Hertroys
On 26 Jan 2010, at 11:00, Yan Cheng Cheok wrote: > However, whenever I insert row into measurement table, I realize its primary > key value is going from 2, 4, 6, 8, 10... > > May I know how can I prevent this? Apparently nextval on that sequence gets called multiple times in your queries. > A

[GENERAL] Primary Key Increment Doesn't Seem Correct Under Table Partition

2010-01-26 Thread Yan Cheng Cheok
Currently, I have a table which I implement table (measurement) partition policy. http://www.postgresql.org/docs/current/static/ddl-partitioning.html Whenever an item being inserted into measurement table, modulo will be perform on measurement table primary key. Then, by using the result of mod