On Thu, Nov 15, 2018 at 02:53:47PM +0900, Amit Langote wrote: > As things stand today, rd_partdesc of a partitioned table must always be > non-NULL. In fact, there are many places in the backend code that Assert it: > > [...]
I have noticed those, and they actually would not care much if rd_partdesc was actually NULL. I find interesting that the planner portion actually does roughly the same thing with a partitioned table with no partitions and a non-partitioned table. > Maybe there are others in a different form. > > If there are no partitions, nparts is 0, and other fields are NULL, though > rd_partdesc itself is never NULL. I find a bit confusing that both concepts have the same meaning, aka that a relation has no partition, and that it is actually relkind which decides rd_partdesc should be NULL or set up. This stuff also does empty allocations. > If we want to redesign that and allow it to be NULL until some code in the > backend wants to use it, then maybe we can consider doing what you say. > But, many non-trivial operations on partitioned tables require the > PartitionDesc, so there is perhaps not much point to designing it such > that rd_partdesc is set only when needed, because it will be referenced > sooner than later. Maybe, we can consider doing that sort of thing for > boundinfo, because it's expensive to build, and not all operations want > the canonicalized bounds. I am fine if that's the consensus of this thread. But as far as I can see it is possible to remove a bit of the memory handling mess by doing so. My 2c. -- Michael
signature.asc
Description: PGP signature
