Horton

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. pg_visibility: Use visibilitymap_count instead of loop.

  1. Vectorize pg_visibility.pg_visibility_map_summary

    Matthias van de Meent <boekewurm+postgres@gmail.com> — 2025-12-22T21:28:09Z

    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)

  2. Re: Vectorize pg_visibility.pg_visibility_map_summary

    Masahiko Sawada <sawada.mshk@gmail.com> — 2025-12-22T22:04:05Z

    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

  3. Re: Vectorize pg_visibility.pg_visibility_map_summary

    Matthias van de Meent <boekewurm+postgres@gmail.com> — 2025-12-22T22:16:39Z

    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)

  4. Re: Vectorize pg_visibility.pg_visibility_map_summary

    wenhui qiu <qiuwenhuifx@gmail.com> — 2025-12-23T04:03:31Z

    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!
>
>
> Kind regards,
>
> Matthias van de Meent
> Databricks (https://www.databricks.com)
>
>
>

  5. Re: Vectorize pg_visibility.pg_visibility_map_summary

    Masahiko Sawada <sawada.mshk@gmail.com> — 2025-12-23T19:40:35Z

    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