Hi On 2019-Mar-25, Andres Freund wrote:
> 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.... Well, this is create index rather than cluster, but yes this conflicts pretty heavily with patch 0008 in your v21 at 20190324031630.nt7numguo5ojq...@alap3.anarazel.de. I wonder if I should rather push and help merge your 0008, or wait until you push and deal with it afterwards. I'd rather do the former, I think. Anyway I was thinking about the conceptual angle -- the progress monitoring stuff is doing block-based reporting. I think even if we get a non-block-based heap, we can still report the number of physical blocks already processed by the scan, which is what the index build monitoring is interested in showing the user. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
