From: | Emmanuel Cecchet <manu(at)frogthinker(dot)org> |
---|---|
To: | Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Nikhil Sontakke <nikhil(dot)sontakke(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1 |
Date: | 2008-11-27 16:09:43 |
Message-ID: | 492EC647.4090706@frogthinker.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Hi all,
I have been following that discussion very closely but it seems that we
are debating solutions without a good specification of the
problem/requirements.
I would suggest that we collect all the partitioning requirements on a
dedicated Wiki page. There might not be a one size fits it all solution
for all requirements. We can also look at what other databases are
proposing to address these issues.
If we can prioritize features, that should also allow us to stage the
partitioning implementation.
I have a prototype insert trigger in C that directly move inserts in a
master table to the appropriate child table (directly moving the tuple).
Let me know if anyone is interested.
Emmanuel
Jaime Casanova wrote:
> On Thu, Nov 27, 2008 at 10:10 AM, Jaime Casanova
> <jcasanov(at)systemguards(dot)com(dot)ec> wrote:
>
>> On Thu, Nov 27, 2008 at 9:41 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>
>>> On Thu, Nov 27, 2008 at 8:31 AM, Gregory Stark <stark(at)enterprisedb(dot)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...
>
>
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: manu(at)frogthinker(dot)org
Skype: emmanuel_cecchet
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2008-11-27 16:38:39 | Re: Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1 |
Previous Message | Tom Lane | 2008-11-27 15:23:05 | Re: A bug with ALTER TABLE SET WITHOUT OIDS in CVS HEAD |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2008-11-27 16:38:39 | Re: Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1 |
Previous Message | Jaime Casanova | 2008-11-27 15:12:13 | Re: Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1 |