Re: Table AM Interface Enhancements - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Table AM Interface Enhancements
Date
Msg-id 20240415194752.lkn5v2rvqy4kjytc@awork3.anarazel.de
Whole thread Raw
In response to Re: Table AM Interface Enhancements  (Pavel Borisov <pashkin.elfe@gmail.com>)
Responses Re: Table AM Interface Enhancements
List pgsql-hackers
Hi,

On 2024-04-15 23:14:01 +0400, Pavel Borisov wrote:
> Why it makes a difference looks a little bit unclear to me, I can't comment
> on this. I noticed that before 041b96802ef we had a block number and block
> sampler state that tied acquire_sample_rows() to the actual block
> structure.

That, and the prefetch calls actually translating the block numbers 1:1 to
physical locations within the underlying file.

And before 041b96802ef they were tied much more closely by the direct calls to
heapam added in 27bc1772fc81.


> After we have the whole struct ReadStream which doesn't comprise just a
> wrapper for the same variables, but the state that ties
> acquire_sample_rows() to the streaming read algorithm (and heap).

Yes ... ? I don't see how that is a meaningful difference to the state as of
27bc1772fc81.  Nor fundamentally worse than the state 27bc1772fc81^, given
that we already issued requests for specific blocks in the file.

That said, I don't like the state after applying
https://postgr.es/m/CAPpHfdvuT6DnguzaV-M1UQ2whYGDojaNU%3D-%3DiHc0A7qo9HBEJw%40mail.gmail.com
because there's too much coupling. Hence talking about needing to iterate on
the interface in some form, earlier in the thread.


What are you actually arguing for here?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Dave Cramer
Date:
Subject: Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
Next
From: Robert Haas
Date:
Subject: Re: Table AM Interface Enhancements