Re: Progress report of CREATE INDEX for nested partitioned tables
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Ilya Gladyshev <ilya.v.gladyshev@gmail.com>,
Matthias van de Meent <boekewurm+postgres@gmail.com>,
Alvaro Herrera <alvherre@alvh.no-ip.org>,
Tomas Vondra <tomas.vondra@enterprisedb.com>,
pgsql-hackers@lists.postgresql.org
Date: 2023-03-25T19:43:32Z
Lists: pgsql-hackers
I pushed 0001 with some cosmetic changes (for instance, trying to make the style of the doc entries for partitions_total/partitions_done match the rest of their table). I'm not touching 0002 or 0003, because I think they're fundamentally a bad idea. Progress reporting is inherently inexact, because it's so hard to predict the amount of work to be done in advance -- have you ever seen a system anywhere whose progress bars reliably advance at a uniform rate? I think adding assertions that the estimates are error-free is just going to cause headaches. As an example, I added a comment pointing out that the current fix won't crash and burn if the caller failed to lock all the child tables in advance: the find_all_inheritors call should be safe anyway, so the worst consequence would be an imprecise partitions_total estimate. But that argument falls down if we're going to add assertions that partitions_total isn't in error. regards, tom lane
Commits
-
Fix CREATE INDEX progress reporting for multi-level partitioning.
- 27f5c712b2c5 16.0 landed