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

From Melanie Plageman
Subject Re: Table AM Interface Enhancements
Date
Msg-id CAAKRu_YakQ3GbFP2YXCBVAE8OmVMCHj9HqKWN7VNbQLpFbg9Cg@mail.gmail.com
Whole thread Raw
In response to Re: Table AM Interface Enhancements  (Andres Freund <andres@anarazel.de>)
Responses Re: Table AM Interface Enhancements
List pgsql-hackers
On Wed, Apr 10, 2024 at 4:33 PM Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On 2024-04-10 16:24:40 -0400, Melanie Plageman wrote:
> > This thread has been moving pretty fast, so could someone point out
> > which version of the patch has the modifications to
> > acquire_sample_rows() that would be relevant for Bilal (and others
> > involved in analyze streaming read) to review? Is it
> > v1-0001-revert-Generalize-relation-analyze-in-table-AM-in.patch?
>
> I think so. It's at least what I've been looking at.

I took a look at this patch, and you're right we will need to do
follow-on work with streaming ANALYZE. The streaming read code will
have to be moved now that acquire_sample_rows() is table-AM agnostic
again.

I don't think there was ever a version that Bilal wrote
where the streaming read code was outside of acquire_sample_rows(). By
the time he got that review feedback, 27bc1772fc8 had gone in.

This brings up a question about the prefetching. We never had to have
this discussion for sequential scan streaming read because it didn't
(and still doesn't) do prefetching. But, if we push the streaming read
code down into the heap AM layer, it will be doing the prefetching.
So, do we remove the prefetching from acquire_sample_rows() and expect
other table AMs to implement it themselves or use the streaming read
API?

- Melanie



pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: ❓ JSON Path Dot Precedence
Next
From: Heikki Linnakangas
Date:
Subject: Re: Improve eviction algorithm in ReorderBuffer