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 2614195.1679764277@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  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Justin Pryzby <pryzby@telsasoft.com> writes:
> On Sat, Mar 25, 2023 at 11:55:13AM -0400, Tom Lane wrote:
>> 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.

I'm a little skeptical of that argument, because this patch is already
redefining the meaning of PARTITIONS_TOTAL.  The fact that the existing
documentation is vague enough to be read either way doesn't make it not
a change.

Still, in the interests of getting something done I'll drop the issue.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: hio.c does visibilitymap_pin()/IO while holding buffer lock
Next
From: Jeff Davis
Date:
Subject: Re: Bug with ICU for merge join