Re: ATTACH/DETACH PARTITION CONCURRENTLY

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