From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrei Lepikhov <lepihov@gmail.com>
cc: Lillian Berry <lillian@star-ark.net>,
        pgsql-performance@lists.postgresql.org, infra@pluralkit.me
Subject: Re: Slow queries on simple index
In-reply-to: <1d79d974-acfe-483c-81da-61989ed2f91b@gmail.com>
References: <aaf503fd-c08c-465d-9d80-4a71abb722c1@app.fastmail.com>
 <1d79d974-acfe-483c-81da-61989ed2f91b@gmail.com>
Comments: In-reply-to Andrei Lepikhov <lepihov@gmail.com>
	message dated "Sat, 17 Jan 2026 21:21:36 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <77029.1768684245.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 17 Jan 2026 16:10:45 -0500
Message-ID: <77030.1768684245@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/77030.1768684245%40sss.pgh.pa.us>
Precedence: bulk

Andrei Lepikhov <lepihov@gmail.com> writes:
> Hmm, where is the evidence that your query uses theindex? Maybe the =

> generic plan accidentally forces SeqScan?

Oh ... you're on to something.  I think we all assumed that this was
an intermittent problem, but if it happens every time, I bet it's a
datatype mismatch issue.  Observe:

postgres=3D# create table members(hid char(6) unique not null);
CREATE TABLE
postgres=3D# prepare p as select * from members where hid =3D '42';
PREPARE
postgres=3D# explain execute p;
                                     QUERY PLAN                           =
           =

--------------------------------------------------------------------------=
-----------
 Index Only Scan using members_hid_key on members  (cost=3D0.15..8.17 rows=
=3D1 width=3D10)
   Index Cond: (hid =3D '42'::bpchar)
(2 rows)
postgres=3D# prepare p2(char) as select * from members where hid =3D $1;
PREPARE
postgres=3D# explain execute p2('42');
                                     QUERY PLAN                           =
           =

--------------------------------------------------------------------------=
-----------
 Index Only Scan using members_hid_key on members  (cost=3D0.15..8.17 rows=
=3D1 width=3D10)
   Index Cond: (hid =3D '42'::bpchar)
(2 rows)
postgres=3D# prepare p3(text) as select * from members where hid =3D $1;
PREPARE
postgres=3D# explain execute p3('42');
                        QUERY PLAN                        =

----------------------------------------------------------
 Seq Scan on members  (cost=3D0.00..42.10 rows=3D11 width=3D10)
   Filter: ((hid)::text =3D '42'::text)
(2 rows)

If the $1 parameter is declared to be type "text" then it wins the
tug-of-war over which equals operator is used, and text-equals-text
does not match the bpchar index.

If it's not convenient to alter whatever aspect of the client logic is
causing that parameter to be marked as text, you could force the issue
by putting a cast into the text of the statement:

postgres=3D# prepare p4(text) as select * from members where hid =3D $1::c=
har(6);
PREPARE
postgres=3D# explain execute p4('42');
                                     QUERY PLAN                           =
           =

--------------------------------------------------------------------------=
-----------
 Index Only Scan using members_hid_key on members  (cost=3D0.15..8.17 rows=
=3D1 width=3D10)
   Index Cond: (hid =3D '42    '::character(6))
(2 rows)

Or better yet, avoid using char(n).  It's a legacy type with no
real reason to exist, and it has semantic gotchas beyond this one.
varchar(n) is a much better idea.

			regards, tom lane