Re: [HACKERS] expanding inheritance in partition bound order

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] expanding inheritance in partition bound order
Дата
Msg-id CA+TgmobB=igJ3dWDqAJ8ySktCmhkxNdPEZaw314RSPjPbb0iUQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] expanding inheritance in partition bound order  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Ответы Re: [HACKERS] expanding inheritance in partition bound order  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
On Mon, Aug 28, 2017 at 6:38 AM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Custom allocators in libpq
Следующее
От: Aaron Patterson
Дата:
Сообщение: Re: [HACKERS] Custom allocators in libpq