Re: Progress report of CREATE INDEX for nested partitioned tables - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Progress report of CREATE INDEX for nested partitioned tables
Date
Msg-id 2586913.1679759713@sss.pgh.pa.us
Whole thread Raw
In response to Re: Progress report of CREATE INDEX for nested partitioned tables  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: Progress report of CREATE INDEX for nested partitioned tables  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
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?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Joseph Koshakow
Date:
Subject: Re: Infinite Interval
Next
From: Noah Misch
Date:
Subject: Re: running logical replication as the subscription owner