Vectorize pg_visibility.pg_visibility_map_summary

From: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Nathan Bossart <nathandbossart(at)gmail(dot)com>, Ants Aasma <ants(dot)aasma(at)cybertec(dot)at>
Subject: Vectorize pg_visibility.pg_visibility_map_summary
Date: 2025-12-22 21:28:09
Message-ID: CAEze2WgPu-EYYuYQimy=AHQHGa7w8EvLVve5DM5eGMR6zh-7sw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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)

Attachment Content-Type Size
v1-0001-pg_visibility-Use-visibilitymap_count-instead-of-.patch application/octet-stream 2.2 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2025-12-22 21:38:31 Re: [PATCH] O_CLOEXEC not honored on Windows - handle inheritance chain
Previous Message Masahiko Sawada 2025-12-22 21:22:38 Re: Orphaned records in pg_replication_origin_status after subscription drop