On Wed, May 15, 2024 at 2:18 PM Nazir Bilal Yavuz <byavu...@gmail.com> wrote: > > On Mon, 29 Apr 2024 at 18:41, Nazir Bilal Yavuz <byavu...@gmail.com> wrote: > > > > On Mon, 8 Apr 2024 at 04:21, Thomas Munro <thomas.mu...@gmail.com> wrote: > > I wanted to discuss what will happen to this patch now that > > 27bc1772fc8 is reverted. I am continuing this thread but I can create > > another thread if you prefer so. > > 041b96802ef is discussed in the 'Table AM Interface Enhancements' > thread [1]. The main problems discussed about this commit is that the > read stream API is not pushed to the heap-specific code and, because > of that, the other AM implementations need to use read streams. To > push read stream API to the heap-specific code, it is pretty much > required to pass BufferAccessStrategy and BlockSamplerData to the > initscan(). > > I am sharing the alternative version of this patch. The first patch > just reverts 041b96802ef and the second patch is the alternative > version. > > In this alternative version, the read stream API is not pushed to the > heap-specific code, but it is controlled by the heap-specific code. > The SO_USE_READ_STREAMS_IN_ANALYZE flag is introduced and set in the > heap-specific code if the scan type is 'ANALYZE'. This flag is used to > decide whether streaming API in ANALYZE will be used or not. If this > flag is set, this means heap AMs and read stream API will be used. If > it is not set, this means heap AMs will not be used and code falls > back to the version before read streams.
Personally, I think the alternative version here is the best option other than leaving what is in master. However, I would vote for keeping what is in master because 1) where we are in the release timeline and 2) the acquire_sample_rows() code, before streaming read, was totally block-based anyway. If we kept what was in master, do we need to document for table AMs how to use read_stream_next_buffer() or can we assume they will look at the heap AM implementation? - Melanie
