Re: index prefetching

From: Konstantin Knizhnik <knizhnik(at)garret(dot)ru>
To: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: index prefetching
Date: 2024-01-22 06:35:59
Message-ID: 316ca3df-d1b0-49ce-ba05-56b342b4cefa@garret.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 22/01/2024 1:47 am, Tomas Vondra wrote:
> h, right. Well, you're right in this case we perhaps could set just one
> of those flags, but the "purpose" of the two places is quite different.
>
> The "prefetch" flag is fully controlled by the prefetcher, and it's up
> to it to change it (e.g. I can easily imagine some new logic touching
> setting it to "false" for some reason).
>
> The "data" flag is fully controlled by the custom callbacks, so whatever
> the callback stores, will be there.
>
> I don't think it's worth simplifying this. In particular, I don't think
> the callback can assume it can rely on the "prefetch" flag.
>
Why not to add "all_visible" flag to IndexPrefetchEntry ? If will not
cause any extra space overhead (because of alignment), but allows to
avoid dynamic memory allocation (not sure if it is critical, but nice to
avoid if possible).

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2024-01-22 06:38:07 Re: Things I don't like about \du's "Attributes" column
Previous Message Peter Smith 2024-01-22 06:33:26 Re: pg_stat_statements and "IN" conditions