Re: Regarding the necessity of RelationGetNumberOfBlocks for every rescan / bitmap heap scan.

On Sat, May 29, 2021 at 11:23 AM Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> wrote:

> Hi:
>
> I'm always confused about the following codes.
>
> static void
> initscan(HeapScanDesc scan, ScanKey key, bool keep_startblock)
> {
> ParallelBlockTableScanDesc bpscan = NULL;
> bool allow_strat;
> bool allow_sync;
>
> /*
> * Determine the number of blocks we have to scan.
> *
> * It is sufficient to do this once at scan start, since any tuples added
> * while the scan is in progress will be invisible to my snapshot anyway.
> * (That is not true when using a non-MVCC snapshot. However, we couldn't
> * guarantee to return tuples added after scan start anyway, since they
> * might go into pages we already scanned. To guarantee consistent
> * results for a non-MVCC snapshot, the caller must hold some higher-level
> * lock that ensures the interesting tuple(s) won't change.)
> */
> if (scan->rs_base.rs_parallel != NULL)
> {
> bpscan = (ParallelBlockTableScanDesc) scan->rs_base.rs_parallel;
> scan->rs_nblocks = bpscan->phs_nblocks;
> }
> else
> scan->rs_nblocks = RelationGextNumberOfBlocks(scan->rs_base.rs_rd);
>
>
> ..
> }
>
> 1. Why do we need scan->rs_nblocks =
> RelationGextNumberOfBlocks(scan->rs_base.rs_rd) for every rescan, which
> looks
> mismatched with the comments along the code. and the comments looks
> reasonable to me.
>

To be more precise, this question can be expressed as if the relation size
can be changed during rescan. We are sure that the size can be increased
due to
new data, but we are sure that the new data is useless for the query as
well. So
looks this case is ok. and for the file size decreasing, since we have lock
on
the relation, so the file size would not be reduced as well (I have verified
this logic on the online vacuum case, other cases should be similar as
well).

--
Best Regards
Andy Fan (https://www.aliyun.com/)