From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: expanding inheritance in partition bound order |
Date: | 2017-08-28 19:26:58 |
Message-ID: | CA+TgmobB=igJ3dWDqAJ8ySktCmhkxNdPEZaw314RSPjPbb0iUQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 28, 2017 at 6:38 AM, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> I am worried about the open relcache reference in PartitionDispatch when
> we start using it in the planner. Whereas there is a ExecEndModifyTable()
> as a suitable place to close that reference, there doesn't seem to exist
> one within the planner, but I guess we will have to figure something out.
Yes, I think there's no real way to avoid having to figure that out.
> OK, done this way in the attached updated patch. Any suggestions about a
> better name for what the patch calls PartitionTupleRoutingInfo?
I think this patch could be further simplified by continuing to use
the existing function signature for RelationGetPartitionDispatchInfo
instead of changing it to return a List * rather than an array. I
don't see any benefit to such a change. The current system is more
efficient.
I keep having the feeling that this is a big patch with a small patch
struggling to get out. Is it really necessary to change
RelationGetPartitionDispatchInfo so much or could you just do a really
minimal surgery to remove the code that sets the stuff we don't need?
Like this:
diff --git a/src/backend/catalog/partition.c b/src/backend/catalog/partition.c
index 96a64ce6b2..4fabcf9f32 100644
--- a/src/backend/catalog/partition.c
+++ b/src/backend/catalog/partition.c
@@ -1089,29 +1089,7 @@ RelationGetPartitionDispatchInfo(Relation rel,
pd[i] = (PartitionDispatch) palloc(sizeof(PartitionDispatchData));
pd[i]->reldesc = partrel;
pd[i]->key = partkey;
- pd[i]->keystate = NIL;
pd[i]->partdesc = partdesc;
- if (parent != NULL)
- {
- /*
- * For every partitioned table other than root, we must store a
- * tuple table slot initialized with its tuple descriptor and a
- * tuple conversion map to convert a tuple from its parent's
- * rowtype to its own. That is to make sure that we are looking at
- * the correct row using the correct tuple descriptor when
- * computing its partition key for tuple routing.
- */
- pd[i]->tupslot = MakeSingleTupleTableSlot(tupdesc);
- pd[i]->tupmap = convert_tuples_by_name(RelationGetDescr(parent),
- tupdesc,
-
gettext_noop("could not convert row type"));
- }
- else
- {
- /* Not required for the root partitioned table */
- pd[i]->tupslot = NULL;
- pd[i]->tupmap = NULL;
- }
pd[i]->indexes = (int *) palloc(partdesc->nparts * sizeof(int));
/*
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Aaron Patterson | 2017-08-28 19:59:20 | Re: Custom allocators in libpq |
Previous Message | Tom Lane | 2017-08-28 19:11:26 | Re: Custom allocators in libpq |