From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
Subject: | Re: ATTACH/DETACH PARTITION CONCURRENTLY |
Date: | 2018-11-15 06:22:04 |
Message-ID: | 20181115062204.GD1374@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2018-11-15 06:31:02 | Re: Accounting of zero-filled buffers in EXPLAIN (BUFFERS) |
Previous Message | Amit Kapila | 2018-11-15 06:18:42 | Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query |