Received: from localhost (maia-5.hub.org [200.46.204.182])
	by postgresql.org (Postfix) with ESMTP id CF2899FB959
	for <pgsql-hackers-postgresql.org@postgresql.org>;
	Tue,  3 Apr 2007 12:36:21 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024)
	with ESMTP id 13897-03 for
	<pgsql-hackers-postgresql.org@postgresql.org>;
	Tue,  3 Apr 2007 12:36:16 -0300 (ADT)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4
Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168])
	by postgresql.org (Postfix) with ESMTP id 3EF5C9FB9C8
	for <pgsql-hackers@postgresql.org>;
	Tue,  3 Apr 2007 12:36:15 -0300 (ADT)
Received: by ug-out-1314.google.com with SMTP id k3so312683ugf
	for <pgsql-hackers@postgresql.org>;
	Tue, 03 Apr 2007 08:36:11 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
	b=qSbUzPakrlCKvPFrApZZweNv0dz8W2vT+UU4mLFCV8ZoXaxZrdwEZuXuCYOSLgQBqvjfLFA8c5vmWSuYEZlj9oV2No8Q97RatiPv8FfaTiGm68Q2DUyNMugvcBXmJJ7TRMErkSbqrkbZzD0lTFY0jGG1zg+psqFrqhp4+cWtXLo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
	b=f2ivwMKDCqaLgr+2gbCfpHng8r380j8ZKgSI0m5e57iHDK4nLuC4gWhKmtP7TbgMzAlCrgCmA3LxRD5QLNbAdvLAAI99UplwLbaPZ42FFwmqMEetIQUT7UgGCQ5eiqYlQibJVtiSlUYoBuwpxDJfMAyfuIO8DpiqFsi9VEyv258=
Received: by 10.82.186.5 with SMTP id j5mr9881622buf.1175614570673;
	Tue, 03 Apr 2007 08:36:10 -0700 (PDT)
Received: by 10.82.139.15 with HTTP; Tue, 3 Apr 2007 08:36:10 -0700 (PDT)
Message-ID: <d3c4af540704030836o242c49cl2688ab4ec9808ac3@mail.gmail.com>
Date: Tue, 3 Apr 2007 21:06:10 +0530
From: NikhilS <nikkhils@gmail.com>
To: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: Auto Partitioning Patch - WIP version 1
In-Reply-To: <d3c4af540703292358s8ed731el7771ab14083aa610@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_8456_27398011.1175614570530"
References: <d3c4af540703292358s8ed731el7771ab14083aa610@mail.gmail.com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200704/152
X-Sequence-Number: 101485

------=_Part_8456_27398011.1175614570530
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,

>
> The following things are TODOs:
>
> iv) Auto generate rules using the checks mentioned for the partitions, to
> handle INSERTs/DELETEs/UPDATEs to navigate them to the appropriate child.
> Note that checks specified directly on the master table will get inherited
> automatically.


Am planning to do the above by using the check constraint specified for each
partition. This constraint's raw_expr field ends up becoming the whereClause
for the rule specific to that partition.

One question is whether we should we allow auto creation of UPDATE rules
given that updates can end up spanning multiple partitions if the column on
which partitioning is specified gets updated?

Also if we decide to auto - add rules for UPDATE, the raw_expr will need to
be modified to refer to "OLD."col, which can be quite a headache. We do not
have parsetree walker/mutator functions as far as I could see in the code.

Regards,
Nikhils

-- 
EnterpriseDB               http://www.enterprisedb.com

------=_Part_8456_27398011.1175614570530
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi, <br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><font face="Arial, Helvetica, sans-serif"><br>The following things are TODOs:<br>
<br></font><font face="Arial, Helvetica, sans-serif">iv) <span id="st" name="st" class="st">Auto</span> generate rules using the checks mentioned for the partitions, to handle
INSERTs/DELETEs/UPDATEs to navigate them to the appropriate child. Note
that checks specified directly on the master table will get inherited
automatically. </font></blockquote><div><br>Am planning to do the above by using the check constraint specified for each partition. This constraint&#39;s raw_expr field ends up becoming the whereClause for the rule specific to that partition.
<br><br>One question is whether we should we allow auto creation of UPDATE rules given that updates can end up spanning multiple partitions if the column on which partitioning is specified gets updated? <br><br>Also if we decide to auto - add rules for UPDATE, the raw_expr will need to be modified to refer to &quot;OLD.&quot;col, which can be quite a headache. We do not have parsetree walker/mutator functions as far as I could see in the code.
<br><br>Regards,<br>Nikhils<br><br></div></div>-- <br>EnterpriseDB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://www.enterprisedb.com">http://www.enterprisedb.com</a>

------=_Part_8456_27398011.1175614570530--