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 http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
