Hi,
On 2021-03-16 18:48:08 +0000, Stephen Frost wrote:
> Use pre-fetching for ANALYZE
>
> When we have posix_fadvise() available, we can improve the performance
> of an ANALYZE by quite a bit by using it to inform the kernel of the
> blocks that we're going to be asking for. Similar to bitmap index
> scans, the number of buffers pre-fetched is based off of the
> maintenance_io_concurrency setting (for the particular tablespace or,
> if not set, globally, via get_tablespace_maintenance_io_concurrency()).
I just looked at this as part of debugging a crash / hang in the AIO patch.
The code does:
block_accepted = table_scan_analyze_next_block(scan, targblock,
vac_strategy);
#ifdef USE_PREFETCH
/*
* When pre-fetching, after we get a block, tell the kernel
about the
* next one we will want, if there's any left.
*
* We want to do this even if the
table_scan_analyze_next_block() call
* above decides against analyzing the block it picked.
*/
if (prefetch_maximum && prefetch_targblock !=
InvalidBlockNumber)
PrefetchBuffer(scan->rs_rd, MAIN_FORKNUM,
prefetch_targblock);
#endif
I.e. we lock a buffer and *then* we prefetch another buffer. That seems like a
quite bad idea to me. Why are we doing IO while holding a content lock, if we
can avoid it?
Greetings,
Andres Freund
