Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 5C09064FCE6 for ; Thu, 27 Nov 2008 12:16:29 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 02797-01 for ; Thu, 27 Nov 2008 12:16:26 -0400 (AST) X-Greylist: delayed 00:06:38.30229 by SQLgrey-1.7.6 Received: from outbound-mail-10.bluehost.com (outbound-mail-10.bluehost.com [69.89.17.210]) by mail.postgresql.org (Postfix) with SMTP id 51B9264FC93 for ; Thu, 27 Nov 2008 12:16:26 -0400 (AST) Received: (qmail 1209 invoked by uid 0); 27 Nov 2008 16:09:43 -0000 Received: from unknown (HELO fast22.fastdomain.com) (74.220.199.22) by outboundproxy1.bluehost.com with SMTP; 27 Nov 2008 16:09:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=frogthinker.org; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=rMxWmPLDWmJ3w9mH3NznGT546L7l9JTBHqNazTxBtCJuiHxcT0Opw7IFKKmeJwhizZSwLV7KMF65qYKcdiLMazZYQmTH3VDtgo9gtwUo94cTGfNkGIKlCJpt5UNY0JSm; Received: from c-71-192-35-139.hsd1.ma.comcast.net ([71.192.35.139] helo=[192.168.0.13]) by fast22.fastdomain.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1L5jQz-0006Ln-V5; Thu, 27 Nov 2008 09:09:42 -0700 Message-ID: <492EC647.4090706@frogthinker.org> Date: Thu, 27 Nov 2008 11:09:43 -0500 From: Emmanuel Cecchet Organization: Frog Thinker User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Jaime Casanova CC: Robert Haas , Gregory Stark , Alvaro Herrera , Nikhil Sontakke , PostgreSQL-development Subject: Re: Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1 References: <3073cc9b0810220744y987173avd560a33fcb58ede5@mail.gmail.com> <603c8f070811261352ta6da0b8xcbb8aaf87f050e6e@mail.gmail.com> <3073cc9b0811261613l18e5283ft448ea74fed414dd@mail.gmail.com> <603c8f070811262009v459d0701w151c16533d4ab947@mail.gmail.com> <20081127120402.GC4586@alvh.no-ip.org> <603c8f070811270507i36e18e0bu5d461a4f957e24d3@mail.gmail.com> <871vwxpa7b.fsf@oxford.xeocode.com> <603c8f070811270641u55bbf340p3383dcc6a6f1f6e8@mail.gmail.com> <3073cc9b0811270710p3a2e5ae9s10f66b529550c03e@mail.gmail.com> <3073cc9b0811270712l6384c28awac4f0318c704df99@mail.gmail.com> In-Reply-To: <3073cc9b0811270712l6384c28awac4f0318c704df99@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {2846:fast22.fastdomain.com:frogthin:frogthinker.org} {sentby:smtp auth 71.192.35.139 authed with manu+frogthinker.org} X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.41 tagged_above=0 required=5 tests=SUBJECT_FUZZY_TION=0.41 X-Spam-Level: X-Archive-Number: 200811/1825 X-Sequence-Number: 128537 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 > wrote: > >> On Thu, Nov 27, 2008 at 9:41 AM, Robert Haas wrote: >> >>> On Thu, Nov 27, 2008 at 8:31 AM, Gregory Stark 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@frogthinker.org Skype: emmanuel_cecchet