From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com> |
Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Subject: | Re: UPDATE of partition key |
Date: | 2017-11-06 19:03:29 |
Message-ID: | CA+TgmoY3qGT-gvXY772-8C7TjARwWzakWb+CtrYY61mzokUQrQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 25, 2017 at 11:40 AM, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com> wrote:
> Below I have addressed the remaining review comments :
The changes to trigger.c still make me super-nervous. Hey THOMAS
MUNRO, any chance you could review that part?
+ /* The caller must have already locked all the partitioned tables. */
+ root_rel = heap_open(root_relid, NoLock);
+ *all_part_cols = NULL;
+ foreach(lc, partitioned_rels)
+ {
+ Index rti = lfirst_int(lc);
+ Oid relid = getrelid(rti, rtables);
+ Relation part_rel = heap_open(relid, NoLock);
+
+ pull_child_partition_columns(part_rel, root_rel, all_part_cols);
+ heap_close(part_rel, NoLock);
I don't like the fact that we're opening and closing the relation here
just to get information on the partitioning columns. I think it would
be better to do this someplace that already has the relation open and
store the details in the RelOptInfo. set_relation_partition_info()
looks like the right spot.
+void
+pull_child_partition_columns(Relation rel,
+ Relation parent,
+ Bitmapset **partcols)
This code has a lot in common with is_partition_attr(). I'm not sure
it's worth trying to unify them, but it could be done.
+ * 'num_update_rri' : number of UPDATE per-subplan result rels. For INSERT,
Instead of " : ", you could just write "is the".
+ * For Updates, if the leaf partition is already present in the
+ * per-subplan result rels, we re-use that rather than
initialize a
+ * new result rel. The per-subplan resultrels and the
resultrels of
+ * the leaf partitions are both in the same canonical
order. So while
It would be good to explain the reason. Also, Updates shouldn't be
capitalized here.
+ Assert(cur_update_rri <= update_rri +
num_update_rri - 1);
Maybe just cur_update_rri < update_rri + num_update_rri, or even
current_update_rri - update_rri < num_update_rri.
Also, +1 for Amit Langote's idea of trying to merge
mt_perleaf_childparent_maps with mt_persubplan_childparent_maps.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2017-11-06 20:23:20 | Re: MERGE SQL Statement for PG11 |
Previous Message | Peter Geoghegan | 2017-11-06 18:35:37 | Re: MERGE SQL Statement for PG11 |