Josh Berkus writes:
> -- INSERT INTO should automatically create new partitions where necessary
> new tables should automatically inherit all constraints, indexes,
> keys of "parent" table
I think you're going about this backwards.
Phase I should be an entirely manual syst
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Hmm. You are right, but without that we won't be able to enforce
> uniqueness on the partitioned table (we could only enforce it on each
> partition, which would mean we can't partition on anything else than
> primary keys if the tables have one). IMHO
On Sun, 2005-03-20 at 00:29 -0400, Alvaro Herrera wrote:
> On Sat, Mar 19, 2005 at 07:05:53PM -0500, Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > We probably also need multi-table indexes.
> >
> > As Josh says, that seems antithetical to the main point of partitioning,
> >
On Sat, Mar 19, 2005 at 07:05:53PM -0500, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > We probably also need multi-table indexes.
>
> As Josh says, that seems antithetical to the main point of partitioning,
> which is to be able to rapidly remove (and add) partitions of a table
On Sat, Mar 19, 2005 at 07:03:19PM -0500, Tom Lane wrote:
> Possibly, but I'm concerned about locking and deadlock issues. The
> reason that this is iffy is you would start the operation with only
> an INSERT-grade lock, and then discover that you needed to add a
> partition, which is surely somet
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> We probably also need multi-table indexes.
As Josh says, that seems antithetical to the main point of partitioning,
which is to be able to rapidly remove (and add) partitions of a table.
If you have to do index cleaning before you can drop a partition,
Josh Berkus writes:
>>> -- INSERT INTO should automatically create new partitions where necessary
>>> -- DELETE FROM should automatically drop empty partitions
>>
>> I am not sure I agree with either of those, and the reason is that they
>> would turn low-lock operations into high-lock operations
tableoid would accomplish that already, assuming that the "partitioned
table" is effectively a view on separate physical tables.
regards, tom lane
Very good.
Also note the possibility to mark a partition READ ONLY. Or even a table.
It does not seem very useful but just think that for inst
On Sat, Mar 19, 2005 at 12:02:38PM -0800, Josh Berkus wrote:
> Folks,
>
> I may (or may not) soon have funding for implementing full table partitioning
> in PostgreSQL. I thought it would be a good idea to discuss with people here
> who are already using pseudo-partitioning what things need to
Tom, Stacy, Alvaro,
> I'd rather see the partition control stuff as ALTER TABLE commands,
> not decoration on CREATE TABLE. See the WITH OIDS business we just went
> through: adding nonstandard decoration to a standard command isn't good.
OK, sure.
> > -- INSERT INTO should automatically create
PFC <[EMAIL PROTECTED]> writes:
> Some ideas :
> hidden field (like oid was) to indicate in which partition the tuple is
> ?
tableoid would accomplish that already, assuming that the "partitioned
table" is effectively a view on separate physical tables.
regard
On Sat, Mar 19, 2005 at 11:24:39PM +0100, PFC wrote:
> Some ideas :
> hidden field (like oid was) to indicate in which partition the tuple
> is ?
I think that to make partitioning really possible we need to have
multi-relfilenode tables.
We probably also need multi-table index
From: "Tom Lane" <[EMAIL PROTECTED]>
> Josh Berkus writes:
> > -- INSERT INTO should automatically create new partitions where
necessary
> > -- DELETE FROM should automatically drop empty partitions
>
> I am not sure I agree with either of those, and the reason is that they
> would turn low-lock o
This is really great !
Think about altering the partitioning (this is quite complex) : imagine a
table split in several partitions "archive" and "current" where a row is
moved from current to archive when it will not be updated anymore.
Sometimes you can partition on a simple numeric val
Josh Berkus writes:
> -- CREATE TABLE ... WITH PARTITION ON {expression}
I'd rather see the partition control stuff as ALTER TABLE commands,
not decoration on CREATE TABLE. See the WITH OIDS business we just went
through: adding nonstandard decoration to a standard command isn't good.
> -- INSE
Folks,
I may (or may not) soon have funding for implementing full table partitioning
in PostgreSQL. I thought it would be a good idea to discuss with people here
who are already using pseudo-partitioning what things need to be added to
Postgresql in order to make full paritioning a reality; th
The most recent version of this thread starts here:
http://archives.postgresql.org/pgsql-general/2005-03/msg00321.php .
Search the archives for "table partition", "union view" and "partition
inherits" and you should find most relevant discussions.
Hope that helps!
On Thu, 17 Mar 2005 15:01:43 +
17 matches
Mail list logo
