On Mon, Aug 7, 2017 at 2:35 PM, Amit Langote
<Langote_Amit_f8@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
http://www.enterprisedb.com