From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
Cc: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ON CONFLICT DO UPDATE for partitioned tables |
Date: | 2018-03-16 15:13:03 |
Message-ID: | 20180316151303.rml2p5wffn3o6qy6@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Pavan Deolasee wrote:
> Hmm, yeah, probably you're right. The reason I got confused is because the
> patch uses ri_onConflictSetProj/ri_onConflictSetWhere to store the
> converted projection info/where clause for a given partition in its
> ResultRelationInfo. So I was wondering if we can
> move mt_arbiterindexes, mt_existing and mt_conflproj to ResultRelInfo and
> then just use that per-partition structures too.
I wonder if the proposed structure is good actually.
Some notes as I go along.
1. ModifyTableState->mt_arbiterindexes is just a copy of
ModifyTable->arbiterIndexes. So why do we need it? For an
unpartitioned relation we can just use
ModifyTableState.ps->arbiterIndexes. Now, for each partition we need to
map these indexes onto the partition indexes. Not sure where to put
these; I'm tempted to say ResultRelInfo is the place. Maybe the list
should always be in ResultRelInfo instead of the state/plan node? Not
sure.
2. We don't need mt_existing to be per-relation; a single tuple slot can
do for all partitions; we just need to ExecSlotSetDescriptor to the
partition's descriptor whenever the slot is going to be used. (This
means the slot no longer has a fixed tupdesc. That seems OK).
3. ModifyTableState->mt_conflproj is more or less the same thing; the
same TTS can be reused by all the different projections, as long as we
set the descriptor before projecting. So we don't
need PartitionTupleRouting->partition_conflproj_slots, but we do need a
descriptor to be used when needed. Let's say
PartitionTupleRouting->partition_confl_tupdesc
I'll experiment with these ideas and see where that leads me.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2018-03-16 15:26:51 | Re: MCV lists for highly skewed distributions |
Previous Message | Stephen Frost | 2018-03-16 15:12:44 | Re: PATCH: Configurable file mode mask |