Re: monitoring CREATE INDEX [CONCURRENTLY]
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Pg Hackers <pgsql-hackers@lists.postgresql.org>, David Fetter <david@fetter.org>, Robert Haas <robertmhaas@gmail.com>, Rahila Syed <rahila.syed@2ndquadrant.com>, Simon Riggs <simon@2ndquadrant.com>, Pavan Deolasee <pavan.deolasee@gmail.com>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Date: 2019-03-26T02:18:09Z
Lists: pgsql-hackers
Hi, On 2019-03-25 23:11:00 -0300, Alvaro Herrera wrote: > On 2019-Mar-25, Alvaro Herrera wrote: > > > Here's v6 of this patch. I have rebased on top of today's CLUSTER > > monitoring, as well as on table AM commits. The latter caused a bit of > > trouble, as now the number of blocks processed by a scan is not as easy > > to get as before; I added a new entry point heapscan_get_blocks_done on > > heapam.c to help with that. (I suppose this will need some fixups later > > on.) > > Andres, I suppose you have something to say about patch 0001 here? I've not followed this thread at all, so I might just be out of my depth here. From my POV, a later patch in the yet-to-be-applied patchqueue moves the main part of cluster below the table AM (as there's enough low level details, e.g. dealing with HOT). Therefore I don't have a problem having heap's implementation interrogate the scan in a heap specific manner. Is that the angle you were wondering about? If not, any chance to point out more precisely what to look at? Obviously out of pure laziness, I'd prefer this to go in after my move of index creation scans & cluster below tableam.h. But admittedly, managing my exhaustion isn't the the sole goal of the project.... Greetings, Andres Freund
Commits
-
Report progress of REINDEX operations
- 03f9e5cba0ee 12.0 landed
-
Report progress of CREATE INDEX operations
- ab0dfc961b6a 12.0 landed
-
Fix error handling of readdir() port implementation on first file lookup
- 754b90f657bd 12.0 cited