On Mon, Aug 7, 2017 at 2:35 PM, Amit Langote
<langote_amit...@lab.ntt.co.jp> wrote:
> On 2017/08/07 10:58, Thomas Munro wrote:
>> Of course there are other usage patterns where you might prefer it
>> this way, because you'll mostly be inserting into partitions created
>> before the change.  In general, would it be better for the partitioned
>> table's TupleDesc to match partitions created before or after a
>> change?  Since partitioned tables have no storage themselves, is there
>> any technical reason we couldn't remove a partitioned table's dropped
>> pg_attribute so that its TupleDesc matches partitions created later?
> That means the parent's TupleDesc will begin mismatching that of all of
> the existing partitions and they will suddenly need a map where they
> didn't before.

True, that doesn't sound great, but eventually you'd stop doing it in
common usage patterns.

> I guess you considered it, but optimizing for the common case of range
> partitioning where most of the inserts go to the newest partition will
> hurt the other partitioning methods, like hash, where that won't
> necessarily be true.

Right, you wouldn't want to do it there.  I guess with hash
partitioning you wouldn't typically be rotating partitions (dropped
old ones and creating new ones), so the TupleDescs stay in lock-step.

>> Is there some way that tupconvert.c could make this type of difference
>> moot?
> Do you mean the difference arising due to dropped columns in either the
> partitioned table or the table attached as a partition?

Yeah.  I can't think of any way.  I thought for a moment about fast
column removal path involving sliding memory rather than full
deform/reform, but that's uninspiring.  I am not actually proposing
any change here since I have no evidence that there's any real
practical problem.  I just wanted to share the realisation I had
during an off-list discussion about tuple deforming, when considering
whether we actually expect to hit the tuple conversion case often.
Depending on the history of your schema the answer may be: never,
sometimes or always, and once you reach this always state you'll never
get out of it.

Thomas Munro

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to