Re: monitoring CREATE INDEX [CONCURRENTLY] - Mailing list pgsql-hackers

From Andres Freund
Subject Re: monitoring CREATE INDEX [CONCURRENTLY]
Date
Msg-id 20190326021809.se3efuathoetxf2u@alap3.anarazel.de
Whole thread Raw
In response to Re: monitoring CREATE INDEX [CONCURRENTLY]  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: monitoring CREATE INDEX [CONCURRENTLY]
List 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


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] CLUSTER command progress monitor
Next
From: Michael Paquier
Date:
Subject: Re: pg_upgrade: Pass -j down to vacuumdb