Re: index prefetching
Konstantin Knizhnik <knizhnik@garret.ru>
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 18/01/2024 5:57 pm, Tomas Vondra wrote: > 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 > Looks like I was not true, even if it is not index-only scan but index condition involves only index attributes, then heap is not accessed until we find tuple satisfying search condition. Inclusive index case described above (https://commitfest.postgresql.org/46/4352/) is interesting but IMHO exotic case. If keys are actually used in search, then why not to create normal compound index instead?