From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Effect of dropping a partitioned table's column over time |
Date: | 2017-08-07 03:37:54 |
Message-ID: | CAEepm=3DvhVZ7xe4vW8S5z6PZQDgV9_xf7cPRCj2TanXpZASpg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 7, 2017 at 2:35 PM, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2017-08-07 03:38:19 | Re: Effect of dropping a partitioned table's column over time |
Previous Message | Tom Lane | 2017-08-07 03:33:30 | FYI: branch for v11 devel is planned for next week |