"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
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
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
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
"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
> 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
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
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
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?
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
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
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
12 matches
Mail list logo