On Sat, Mar 25, 2023 at 11:55:13AM -0400, Tom Lane wrote: > Justin Pryzby <pry...@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