|From:||Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>|
|To:||Rahila Syed <rahila(dot)syed(at)2ndquadrant(dot)com>|
|Cc:||Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, David Fetter <david(at)fetter(dot)org>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>|
|Subject:||Re: monitoring CREATE INDEX [CONCURRENTLY]|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Hi Rahila, thanks for reviewing.
On 2019-Mar-25, Rahila Syed wrote:
> Please see few comments below:
> 1. Makecheck fails currently as view definition of expected rules.out does
> not reflect latest changes in progress metrics numbering.
Ouch ... fixed.
> 2. + <entry>
> I think there is a typo here 's/partitioned/partitioned table/'
Ah, so there is. Fixed.
> I think parallel scan equivalent bpscan->phs_nblocks along with
> hscan->rs_nblocks should be used similar to startblock computation above.
Hmm, yeah. I think the way things are setup currently it doesn't matter
much, but it seems fragile to rely on that.
I also moved the reporting of total blocks to scan in the initial table
scan so that it occurs wholly in heapam_index_build_range_scan; I had
originally put that code in _bt_spools_heapscan, but that was a
modularity violation I think. (It didn't make a practical difference,
but it made no sense to have the two cases report the number in wildly
different locations.) Also added a final nblocks metric update after
the scan is done.
I think this patch is done.
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
|Next Message||Youssef Khedher||2019-04-01 16:16:13||GCoS2019--pgBackRest port to Windows (2019)|
|Previous Message||David Rowley||2019-04-01 15:23:20||Re: COPY FROM WHEN condition|