[GENERAL] inheritance. more.

2008-04-27 Thread Tom Allison
create table master ( id serial, mdn varchar(11), meid varchar(18), min varchar(11), constraint mmm_master unique (mdn, meid, min) ); insert into master(mdn, meid, min) select mdn, meid, min from test_data where meid != '00' limit 10; Everything works up to this point... insert

Re: [GENERAL] inheritance. more.

2008-04-28 Thread Erik Jones
On Apr 27, 2008, at 8:23 PM, Tom Allison wrote: create table master ( id serial, mdn varchar(11), meid varchar(18), min varchar(11), constraint mmm_master unique (mdn, meid, min) ); insert into master(mdn, meid, min) select mdn, meid, min from test_data where meid != '00' limi

Re: [GENERAL] inheritance. more.

2008-04-28 Thread Gurjeet Singh
On Mon, Apr 28, 2008 at 8:01 PM, Erik Jones <[EMAIL PROTECTED]> wrote: > > Postgres doesn't yet handle inheritance of constraints from parent to > child tables via inheritance. > > Was it done by design or was it a limitation we couldn't get over? Best regards, -- [EMAIL PROTECTED] [EMAIL PROTEC

Re: [GENERAL] inheritance. more.

2008-04-28 Thread Erik Jones
On Apr 28, 2008, at 8:01 PM, Gurjeet Singh wrote: On Mon, Apr 28, 2008 at 8:01 PM, Erik Jones <[EMAIL PROTECTED]> wrote: Postgres doesn't yet handle inheritance of constraints from parent to child tables via inheritance. Was it done by design or was it a limitation we couldn't get over?

Re: [GENERAL] inheritance. more.

2008-04-28 Thread Martijn van Oosterhout
On Tue, Apr 29, 2008 at 06:31:30AM +0530, Gurjeet Singh wrote: > On Mon, Apr 28, 2008 at 8:01 PM, Erik Jones <[EMAIL PROTECTED]> wrote: > > Postgres doesn't yet handle inheritance of constraints from parent to > > child tables via inheritance. > Was it done by design or was it a limitation we coul

Re: [GENERAL] inheritance. more.

2008-04-30 Thread Gurjeet Singh
On Tue, Apr 29, 2008 at 11:47 AM, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote: > On Tue, Apr 29, 2008 at 06:31:30AM +0530, Gurjeet Singh wrote: > > On Mon, Apr 28, 2008 at 8:01 PM, Erik Jones <[EMAIL PROTECTED]> wrote: > > > Postgres doesn't yet handle inheritance of constraints from parent t

Re: [GENERAL] inheritance. more.

2008-04-30 Thread Karsten Hilbert
> And maybe having one huge index managing the uniqueness across partitioned > data just defeats the idea of data partitioning! Except when you want uniqueness across all partitions. Karsten -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://w

Re: [GENERAL] inheritance. more.

2008-04-30 Thread Tom Lane
"Karsten Hilbert" <[EMAIL PROTECTED]> writes: >> And maybe having one huge index managing the uniqueness across partitioned >> data just defeats the idea of data partitioning! > Except when you want uniqueness across all partitions. Well, the point was that if the partitioning arrangement guarant

Re: [GENERAL] inheritance. more.

2008-05-01 Thread Jeremy Harris
Gurjeet Singh wrote: One of the advantages of breaking up your data into partitions, as professed by Simon (I think) (and I agree), is that you have smaller indexes, which improve performance. And maybe having one huge index managing the uniqueness across partitioned data just defeats the idea o

Re: [GENERAL] inheritance. more.

2008-05-01 Thread Nathan Boley
Because people can be smarter about the data partitioning. Consider a table of users. Some are active, most are not. The active users account for nearly all of the users table access, but I still (occasionally) want to access info about the inactive users. Partitioning users into active_users and

Re: [GENERAL] inheritance. more.

2008-05-01 Thread Jeremy Harris
Nathan Boley wrote: Because people can be smarter about the data partitioning. Consider a table of users. Some are active, most are not. The active users account for nearly all of the users table access, but I still (occasionally) want to access info about the inactive users. Partitioning users

Re: [GENERAL] inheritance. more.

2008-05-01 Thread Gregory Stark
"Nathan Boley" <[EMAIL PROTECTED]> writes: > Because people can be smarter about the data partitioning. > > Consider a table of users. Some are active, most are not. The active > users account for nearly all of the users table access, but I still > (occasionally) want to access info about the inac