On Sat, Mar 25, 2023 at 11:55:13AM -0400, Tom Lane wrote:
> Justin Pryzby <pryzby@telsasoft.com> writes:
> > On Thu, Mar 23, 2023 at 04:35:46PM -0400, Tom Lane wrote:
> >> Furthermore, as things stand it's not hard
> >> for PARTITIONS_TOTAL to be zero --- there's at least one such case
> >> in the regression tests --- and that seems just weird to me.
>
> > I don't know why it'd seem weird. postgres doesn't create partitions
> > automatically, so by default there are none. If we create a table but
> > never load any data, it'll have no partitions.
>
> My problem with it is that it's not clear how to tell "no partitioned
> index creation in progress" from "partitioned index creation in progress,
> but total = 0". Maybe there's some out-of-band way to tell that in the
> stats reporting system, but still it's a weird corner case.
>
> > Also, the TOTAL=0 case
> > won't go away just because we start counting intermediate partitions.
>
> That's why I wanted list_length() not list_length() - 1. We are
> doing *something* at the top partitioned table, it just doesn't
> involve a table scan, so I don't find this totally unreasonable.
> If you agree we are doing work at intermediate partitioned tables,
> how are we not doing work at the top one?
What you're proposing would redefine the meaning of
PARTITIONS_DONE/TOTAL, even in the absence of intermediate partitioned
tables. Which might be okay, but the scope of this thread/patch was to
fix the behavior involving intermediate partitioned tables.
It's somewhat weird to me that find_all_inheritors(rel) returns the rel
itself. But it's an internal function, and evidently that's what's
needed/desirable to do, so that's fine.
However, "PARTITIONS_TOTAL" has a certain user-facing definition, and
"Number of partitions" is easier to explain than "Number of partitions
plus the rel itself", and IMO an easier definition is a better one.
Your complaint seems similar to something I've said a few times before:
it's weird to expose macroscopic progress reporting of partitioned
tables in the same view and in the same *row* as microscopic progress of
its partitions. But changing that is a job for another patch. I won't
be opposed to it if someone were to propose a patch to remove
partitions_{done,total}. See also:
https://www.postgresql.org/message-id/flat/YCy5ZMt8xAyoOMmv%40paquier.xyz#b20d1be226a93dacd3fd40b402315105
--
Justin
