Re: index prefetching
Tomas Vondra <tomas.vondra@enterprisedb.com>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
aio: io_uring: Trigger async processing for large IOs
- a9ee66881744 19 (unreleased) landed
-
read stream: Split decision about look ahead for AIO and combining
- 8ca147d582a5 19 (unreleased) landed
-
read_stream: Only increase read-ahead distance when waiting for IO
- f63ca3379025 19 (unreleased) landed
-
read_stream: Prevent distance from decaying too quickly
- 6e36930f9aaf 19 (unreleased) landed
-
Reduce ExecSeqScan* code size using pg_assume()
- b227b0bb4e03 19 (unreleased) cited
-
Fix rare bug in read_stream.c's split IO handling.
- b421223172a2 19 (unreleased) cited
-
Fix multiranges to behave more like dependent types.
- 3e8235ba4f9c 17.0 cited
-
Add EXPLAIN (MEMORY) to report planner memory consumption
- 5de890e3610d 17.0 cited
-
Optimize nbtree backward scan boundary cases.
- c9c0589fda0e 17.0 cited
-
Increment xactCompletionCount during subtransaction abort.
- 90c885cdab8b 14.0 cited
-
Add nbtree Valgrind buffer lock checks.
- 4a70f829d86c 14.0 cited
-
Add nbtree high key "continuescan" optimization.
- 29b64d1de7c7 12.0 cited
-
Reduce pinning and buffer content locking for btree scans.
- 2ed5b87f96d4 9.5.0 cited
-
Teach btree to handle ScalarArrayOpExpr quals natively.
- 9e8da0f75731 9.2.0 cited
On 1/16/24 21:10, Konstantin Knizhnik wrote: > > ... > >> 4. I think that performing prefetch at executor level is really great >>> idea and so prefetch can be used by all indexes, including custom >>> indexes. But prefetch will be efficient only if index can provide fast >>> access to next TID (located at the same page). I am not sure that it is >>> true for all builtin indexes (GIN, GIST, BRIN,...) and especially for >>> custom AM. I wonder if we should extend AM API to make index make a >>> decision weather to perform prefetch of TIDs or not. >> I'm not against having a flag to enable/disable prefetching, but the >> question is whether doing prefetching for such indexes can be harmful. >> I'm not sure about that. > > I tend to agree with you - it is hard to imagine index implementation > which doesn't win from prefetching heap pages. > May be only the filtering case you have mentioned. But it seems to me > that current B-Tree index scan (not IOS) implementation in Postgres > doesn't try to use index tuple to check extra condition - it will fetch > heap tuple in any case. > That's true, but that's why I started working on this: https://commitfest.postgresql.org/46/4352/ I need to think about how to combine that with the prefetching. The good thing is that both changes require fetching TIDs, not slots. I think the condition can be simply added to the prefetch callback. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company