Feedback-ID: i0fe9450f:Fastmail
Date: Fri, 5 Jun 2026 12:32:49 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Baji Shaik <baji.pgdev@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org, pg@bowt.ie
Subject: Re: [PATCH] Add regression tests for btree skip scan support
 functions
Message-ID: <aiJDYR5HtDxM-mCp@paquier.xyz>
References: 
 <CA+fm-RNqXnr_ms365xQnSMcggrGFozbEPrVa+Y_yGYrSky1o2w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="PRNktnHIXKlqJglR"
Content-Disposition: inline
In-Reply-To: 
 <CA+fm-RNqXnr_ms365xQnSMcggrGFozbEPrVa+Y_yGYrSky1o2w@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aiJDYR5HtDxM-mCp%40paquier.xyz>
Precedence: bulk


--PRNktnHIXKlqJglR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Jun 03, 2026 at 07:16:15PM -0500, Baji Shaik wrote:
> These functions feed into the skip-scan optimization added in
> commit 92fe23d93aa for PG18, but the existing regression coverage
> only exercises a few types (mostly int4 and varchar) on the leading
> column of multi-column indexes.

Thanks a lot for this patch.  FWIW, I've noticed the gap a couple of
months ago when adding oid8 but I have not been able to get back to
it, noticing that the gap was wider than only oid8.

> The attached patch adds a small section to btree_index.sql that
> creates a two-column index (a, b) for each missing type, then runs
> forward and backward Index Only Scans with a predicate on the
> non-leading column (b).  This forces the planner into a skip scan,
> which in turn calls the per-type skip-support function plus the
> increment/decrement helpers as it generates skip-array elements.

Could you add this patch to the next commit fest please at [1]?
That's to make sure that we don't forget about it when v20 opens for
business.  I am sure that nobody would complain it this gets applied
on HEAD today (argument that this is an open item for v19 due to
v19?), but that's a coverage improvement so let's just do that once
REL_19_STABLE is forked.

Perhaps we could do something for the overflow cases in the increment
functions of oid, oid8, char, int8 and int4.  int2_increment is
lacking entirely.  For the decrement functions, we still lack
something for the overflow of int2, int8, char.  You can run a
coverage report to check all that:
https://www.postgresql.org/docs/devel/regress-coverage.html

[1]: https://commitfest.postgresql.org/59/
--
Michael

--PRNktnHIXKlqJglR
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmoiQ2EACgkQnvQgOdby
QH3DVA/6Aq+uptBko6lPHCcdZbjgngDW+M0iSysfhY8tbvG8kBMQa2f6k6LsmSMH
wVMxMKRserSZ2DtUxDWjXYmMcQK1IRnrhFSfWoE9c7LANW73JZoObCoV3tA+MaTt
w5oOZ98EXSuVmwg90PLcCLH0H3FfCev4iKG+pyhN/pktFH0auPDFiKrBEJGR3Gpi
5PBxDJvNDJgJ8N6zC9oy0SxLR+WyFLoGgOhQpq/hu8tMx9pGUEidzJkSwq4pgSD5
X2Se8gNP04yQC8IpQcAQzqw0gc1eHWmL+bI5p2rArWAJ3E6O5mBuNYmf+LlfM/y6
VNWXoXZ7/RRGVPMesk7w3hlsYSI8P65QcodB/Y/Ll7eumuLZEUv/osahutJ0A/o0
/ur/sqxY5KBW+gO8LrkUsbDmwkYKl7TI8UkU/CIDR7uwSrEkJBXhxMVKb8XgMsoe
60aTyqN+ut15UZrPEhmiut4CoLPsIZ4srmNU8n0AgPBudk2bWUFYNtGomD63wRZO
BJagDLT4YjYMgjoM05qBUMv4KymTzkWKKHFokIIfjDEWPk85ADbGot38pB0yYWXn
0LAKzW20rbGv0m42gDAu4UfGW65Aib05Z1MmFChLl5YdfWK+6Inkp9zGKBmKkE/a
hp98j6RKN58og6gkJED+gy+w+ratRNxSITYFn0GM1HbmlWbQ7gE=
=jLNh
-----END PGP SIGNATURE-----

--PRNktnHIXKlqJglR--