On 2019-Sep-06, Michael Paquier wrote: > Finally comes the question of what do we do for v12? I am adding in > CC Peter, Alvaro being already present, who have been involved in the > commits with CREATE INDEX and REINDEX. It would be sad to revert a > this feature, but well I'd rather do that now than regret later > releasing the feature as it is currently shaped.. Let's see what the > others think.
As far as I understand, CREATE INDEX is not affected -- only REINDEX is. Of course, it would be sad to revert even the latter, but it's not as bleak as reverting the whole thing. That said, I did spend some time on this type of issue when doing CREATE INDEX support; you can tell because I defined the columns for block numbers in a scan separately from CREATE INDEX specific fields, precisely to avoid multiple commands running concurrently from clobbering unrelated columns: /* Block numbers in a generic relation scan */ #define PROGRESS_SCAN_BLOCKS_TOTAL 15 #define PROGRESS_SCAN_BLOCKS_DONE 16 I would say that it's fairly useful to have CLUSTER report progress on indexes being created underneath, but I understand that it might be too late to be designing the CLUSTER report to take advantage of the CREATE INDEX metrics. I think a workable, not terribly invasive approach is to have REINDEX process its commands conditionally: have the caller indicate whether progress is to be reported, and skip the calls if not. That would (should) prevent it from clobbering the state set up by CLUSTER. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
