Comparing changes

Allows the index AM to provide items (TIDs and tuples) in batches, which is then used to implement prefetching of heap tuples in index scans (including index-only scans). This is similar to prefetching already done in bitmap scans, and can result in significant speedups. The index AM may implement an optional "amgetbatch" callback, returning a batch of items. The indexam.c code then handles this transparently through the existing "getnext" interface. It is up to the index AM to return only batches that it can handle internally. For example, most of the later patches adding support for batching to relevant index AMs (btree, hash, gist, sp-gist) restrict the batches to a single leaf page. This makes implementation of batching much simpler, with only minimal changes to the index AMs, but it's not a hard requirement. The index AM can produce batches spanning arbitrary number of leaf pages. This is left as a possible future improvement. Most of the batching/prefetching logic happens in indexam.c. This means the executor code can continue to call the interface just like before. The only "violation" happens in index-only scans, which need to check the visibility map both when the prefetching pages (we don't want to prefetch pages that are unnecessary) and later when reading the data. For cached data the visibility map checks can be fairly expensive, so it's desirable to keep and reuse the result of the first check. At the moment, the prefetching does not handle mark/restore plans. This is doable, but requires additional synchronization between the batching and index AM code in the "opposite direction". This patch does not actually add batching to any of the index AMs, it's just the common infrastructure. TODO Add the new index AM callback to sgml docs. Re-introduce the callback to check VM and remember the result. It can happen the first few batches (leaf pages) may be returned from the index, skipping the heap fetches. Which means the read stream does no reads until much later after the first batches are already freed. Because the reads only happen when first reading from the stream. In that case we need to be careful about initializing the stream position because setting it to (0,0) would be wrong as the batch is already gone. So just initialize to readPost, which should be initialized already. Could it happen later, or just on first call? Probably first call only, as the read stream always looks ahead for the block that actually needs reading.

Adds batching/prefetching for btree indexes. Returns only batches from a single leaf page. Does not support mark/restore yet.

This branch was automatically generated by a robot using patches from an email thread registered at: https://commitfest.postgresql.org/patch/4351 The branch will be overwritten each time a new patch version is posted to the thread, and also periodically to check for bitrot caused by changes on the master branch. Patch(es): https://www.postgresql.org/message-id/[email protected] Author(s): Tomas Vondra

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Comparing changes

Open a pull request

Commits on Apr 28, 2025

This comparison is taking too long to generate.