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