Обсуждение: Vectorize pg_visibility.pg_visibility_map_summary

Hi,

Whilst working on fixing a bug in GiST and SP-GiST's index-only scan
systems, I noticed that pg_visibility is sometimes rather wasteful
with the APIs which it calls into; especially now that there are more
optimized APIs available.

Here's one small patch that makes it use the visibilitymap_count() API
for pg_visibility_map_summary(), replacing its own bespoke counting
mechanism with the primary implementation that has vectorized
optimizations, thus reducing the overhead of
pg_visibility_map_summary.

CC-ed to authors of 41c51f0c68, visibilitymap_count was optimized, and
this potential user wasn't notified of that.


Kind regards,

Matthias van de Meent
Databricks (https://www.databricks.com)

Hi,

On Mon, Dec 22, 2025 at 1:28 PM Matthias van de Meent
<boekewurm+postgres@gmail.com> wrote:
>
> Hi,
>
> Whilst working on fixing a bug in GiST and SP-GiST's index-only scan
> systems, I noticed that pg_visibility is sometimes rather wasteful
> with the APIs which it calls into; especially now that there are more
> optimized APIs available.
>
> Here's one small patch that makes it use the visibilitymap_count() API
> for pg_visibility_map_summary(), replacing its own bespoke counting
> mechanism with the primary implementation that has vectorized
> optimizations, thus reducing the overhead of
> pg_visibility_map_summary.
>

It looks like a reasonable idea as it also simplifies the
pg_visibility_map_summary() function. I'm going to push it, barring
any objections.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

Hi,

On Mon, 22 Dec 2025 at 23:04, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> On Mon, Dec 22, 2025 at 1:28 PM Matthias van de Meent
> <boekewurm+postgres@gmail.com> wrote:
> > Here's one small patch that makes it use the visibilitymap_count() API
> > for pg_visibility_map_summary(), replacing its own bespoke counting
> > mechanism with the primary implementation that has vectorized
> > optimizations, thus reducing the overhead of
> > pg_visibility_map_summary.
> >
>
> It looks like a reasonable idea as it also simplifies the
> pg_visibility_map_summary() function. I'm going to push it, barring
> any objections.

Obviously no objections from me, and, thanks!


Kind regards,

Matthias van de Meent
Databricks (https://www.databricks.com)

On Mon, Dec 22, 2025 at 8:03 PM wenhui qiu <qiuwenhuifx@gmail.com> wrote:
>
> Hi
>
> > It looks like a reasonable idea as it also simplifies the
> > pg_visibility_map_summary() function. I'm going to push it, barring
> > any objections.
> Obviously no objections, Using visibilitymap_count() simplifies the code and improves performance, with no behavior
change.
>
> Thanks
>
>
> On Tue, Dec 23, 2025 at 6:17 AM Matthias van de Meent <boekewurm+postgres@gmail.com> wrote:
>>
>> Hi,
>>
>> On Mon, 22 Dec 2025 at 23:04, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>> > On Mon, Dec 22, 2025 at 1:28 PM Matthias van de Meent
>> > <boekewurm+postgres@gmail.com> wrote:
>> > > Here's one small patch that makes it use the visibilitymap_count() API
>> > > for pg_visibility_map_summary(), replacing its own bespoke counting
>> > > mechanism with the primary implementation that has vectorized
>> > > optimizations, thus reducing the overhead of
>> > > pg_visibility_map_summary.
>> > >
>> >
>> > It looks like a reasonable idea as it also simplifies the
>> > pg_visibility_map_summary() function. I'm going to push it, barring
>> > any objections.
>>
>> Obviously no objections from me, and, thanks!
>>

Pushed.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com