Disable readstream's reliance on seqscan readahead

[MMeent]

Neon doesn't have seqscan detection of its own, so stop read_stream from trying to utilize that readahead, and instead make it issue readahead of its own.

Problem

@knizhnik noticed that we didn't issue smgrprefetch[v] calls for seqscans in PG17 due to the move to the read_stream API, which assumes that the underlying IO facilities do seqscan detection for readahead. That is a wrong assumption when Neon is involved, so let's remove the code that applies that assumption.

Summary of changes

Remove the cases where seqscans are detected and prefetch is disabled as a consequence, and instead don't do that detection.

[github-actions]

5553 tests run: 5332 passed, 3 failed, 218 skipped (full report)

---

Failures on Postgres 17

• test_postgres_version: release-x86-64, release-arm64, debug-x86-64

# Run all failed tests locally:
scripts/pytest -vv -n $(nproc) -k "test_postgres_version[release-pg17] or test_postgres_version[release-pg17] or test_postgres_version[debug-pg17]"

Flaky tests (1)

Postgres 17

• test_create_churn_during_restart: debug-x86-64

Test coverage report is not available

_{The comment gets automatically updated with the latest test results
9c7cb7a at 2024-11-22T19:54:43.392Z :recycle:}

[knizhnik]

Unfortunately the problem with prefetch in PG17 still can not be considered to be resolved.
Yes, with 9860 prefetch is performed and explain (prefetch) shows 100% prefetch hit rate.
But as far as I understand, now prefetch is performed using StartReadBuffersImpl :

	if (flags & READ_BUFFERS_ISSUE_ADVICE)
	{
		/*
		 * In theory we should only do this if PinBufferForBlock() had to
		 * allocate new buffers above.  That way, if two calls to
		 * StartReadBuffers() were made for the same blocks before
		 * WaitReadBuffers(), only the first would issue the advice. That'd be
		 * a better simulation of true asynchronous I/O, which would only
		 * start the I/O once, but isn't done here for simplicity.  Note also
		 * that the following call might actually issue two advice calls if we
		 * cross a segment boundary; in a true asynchronous version we might
		 * choose to process only one real I/O at a time in that case.
		 */
		smgrprefetch(operation->smgr,
					 operation->forknum,
					 blockNum,
					 operation->io_buffers_len);
	}

But it means that prefetch distance is always 1 and effective_io_concurrency is not take in account.
So no wonder that nax in-flight requests in pg-17 is alays 1.
And this is why pg16 is 5 (five!) times slower on some queries.
I did some local microbenchmarking, simulating 0.2msec network latency:

create table t(pk integer, filler text default repeat('?', 200));
insert into t (pk) values (generate_series(1,100000));
set effective_io_concurrency=100;
set max_parallel_workers_per_gather=0; 
explain (analyze,prefetch,buffers) select sum(pk) from t;

Time of query execution in pg16: 654 msec
Result of pg17: 3570 msec

Reply…
Also send to proj-neon-postgres-v17

product