Re: Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1
От | Jaime Casanova |
---|---|
Тема | Re: Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1 |
Дата | |
Msg-id | 3073cc9b0811270712l6384c28awac4f0318c704df99@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1 ("Jaime Casanova" <jcasanov@systemguards.com.ec>) |
Ответы |
Re: Fwd: [PATCHES] Auto Partitioning Patch - WIP version
1
|
Список | pgsql-hackers |
On Thu, Nov 27, 2008 at 10:10 AM, Jaime Casanova <jcasanov@systemguards.com.ec> wrote: > On Thu, Nov 27, 2008 at 9:41 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> On Thu, Nov 27, 2008 at 8:31 AM, Gregory Stark <stark@enterprisedb.com> wrote: >>>> CREATE PARTITION transaction_2008_11 ON transaction WHERE record_date >>>> BETWEEN '2008-11-01' AND '2008-11-30'; >>> >>> I think the main advantage to a better partitioning method would be teaching >>> Postgres about the partition key. Instead of a collection of different >>> constraints Postgres would know that "record_date" is *always* the partition >>> key. So it wouldn't have to be specified every time you declare a partition. >> >> Hmm... I thought the main advantage would be that you wouldn't have >> to manually add constraints to all of the child tables, and you >> wouldn't have to manually add rules/triggers to the parent table to >> redirect DML operations. >> > > ok. what about let CREATE TABLE WITH PARTITIONING to create an entry > in a catalog indicating the key of the partition and install the > triggers and let the trigger decide if it has the partition to insert > the new row (making UPDATE working almost as DELETE+INSERT if it needs > to change of partitions) or create the new partition maybe with an > apropiate CREATE PARTITION... > i thik i have to clarify this... i intend to say that, the trigger will insert or create the partition and insert... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157
В списке pgsql-hackers по дате отправления: