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/19/24 09:34, Konstantin Knizhnik wrote: > > On 18/01/2024 6:00 pm, Tomas Vondra wrote: >> On 1/17/24 09:45, Konstantin Knizhnik wrote: >>> I have integrated your prefetch patch in Neon and it actually works! >>> Moreover, I combined it with prefetch of leaf pages for IOS and it also >>> seems to work. >>> >> Cool! And do you think this is the right design/way to do this? > > I like the idea of prefetching TIDs in executor. > > But looking though your patch I have some questions: > > > 1. Why it is necessary to allocate and store all_visible flag in data > buffer. Why caller of IndexPrefetchNext can not look at prefetch field? > > + /* store the all_visible flag in the private part of the entry */ > + entry->data = palloc(sizeof(bool)); > + *(bool *) entry->data = all_visible; > What you mean by "prefetch field"? The reason why it's done like this is to only do the VM check once - without keeping the value, we'd have to do it in the "next" callback, to determine if we need to prefetch the heap tuple, and then later in the index-only scan itself. That's a significant overhead, especially in the case when everything is visible. > 2. Names of the functions `IndexPrefetchNext` and > `IndexOnlyPrefetchNext` are IMHO confusing because they look similar and > one can assume that for one is used for normal index scan and last one - > for index only scan. But actually `IndexOnlyPrefetchNext` is callback > and `IndexPrefetchNext` is used in both nodeIndexscan.c and > nodeIndexonlyscan.c > Yeah, that's a good point. The naming probably needs rethinking. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company