Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tfLjK-001h7c-N4 for pgsql-general@arkaria.postgresql.org; Tue, 04 Feb 2025 16:24:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tfLiL-005AS2-KA for pgsql-general@arkaria.postgresql.org; Tue, 04 Feb 2025 16:23:53 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tfLiL-005ARu-98 for pgsql-general@lists.postgresql.org; Tue, 04 Feb 2025 16:23:53 +0000 Received: from mail-oi1-x231.google.com ([2607:f8b0:4864:20::231]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tfLiJ-0039VM-04 for pgsql-general@lists.postgresql.org; Tue, 04 Feb 2025 16:23:52 +0000 Received: by mail-oi1-x231.google.com with SMTP id 5614622812f47-3eba50d6da7so1632378b6e.2 for ; Tue, 04 Feb 2025 08:23:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738686230; x=1739291030; darn=lists.postgresql.org; h=to:subject:message-id:date:from:reply-to:mime-version:from:to:cc :subject:date:message-id:reply-to; bh=R1rewFKwJmIjQyMpqVg0jYoiHIxyVtTFg0/cz+fENvY=; b=Tk8j2DLzsYNT4y8GXrav1UTDHMcyC8hwxmaXH0Ydveg+ftBfYEEeZKKn07TEGhniWP NX7ktqvOArqFcE9cgC6R5ncZ0VrIN87ABAXTC5DNHD3Qrw4OKfWWRwafBuFKOjUP4ZBi RPgyYt+rRIorY4CLmkR0W4SxIzghRfzfoOuviz/K6B/0kitjn28OPeytAapp5Eoc2kYY LipGSY6EGvH3gHTq/EbLqTVLpSmh5u8Sjp26xRg2heJ8ldW8RNUuNDk9JO/+t/NjGdxA c6+YSH3t8cxtTwU2M4V4cI87PY1gPbIXbVDNGEnV8Z4qxdoMHCjAXNEBBbaqKx7Ex0jN rD9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738686230; x=1739291030; h=to:subject:message-id:date:from:reply-to:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=R1rewFKwJmIjQyMpqVg0jYoiHIxyVtTFg0/cz+fENvY=; b=lt2HwK0Z7W4A3bDPK34qeEXiul7Qso+/dxIQ8zJanD4bDEuXAcvypY2SbjUsFYnoo5 ulI9I4t3hmCYE2jOCTiQyXyVGc0u7ak1v/WExAA2ezXYI44gwXgUEwYeHWyLrNPqXvnP L557aMJ2ZIkGjEunp4Vf56+EAZBlxaSe3+krvAQc4D4sADvdGIRl7t462Ezp7jWTpjga A8mpPydpHDR6fbWJ7la3RD0pEMRe2WPInZJEF5n/5aL5CcoqH5manowpvJzcuyEy0H+W EOVcL4gmKzARCvFzXCKkd/Q4jPJ5Bci7drdJ71VhkDNkNFXCIk0Wr7rHeGNv7yIZJ9mC LkWw== X-Gm-Message-State: AOJu0YyWEfQpv2mFhveoCPY79hnQke/yUmSgUiyRgzejwHPhVU6u0pzr GWhhwSSy5cFxIIM6NZ/1VgZ6iiQIpxWFg93yBpd3Fyf1LolJ+AJ92DLf/AaVlXjtc0Ejp7NF6Yi mNCCYsb1oAg7EJ1/gy/OqjA9fY0c6zvQn X-Gm-Gg: ASbGnctha85aMIVbtIG4M6twZgffBGL9MI3wcopMLPAPuCTyqlcNW+H6FSeQCO+xCOt /KeOmL8QrIeJFXcD9XeyCZgLlz9hcOOsFaiG8R0mDBGwBFDHKxyeyQqMjyfUx5JepPGZOwG9r X-Google-Smtp-Source: AGHT+IEkLTarNPtlV+gqxrjinV1dKYnZhuDjCmxk1WEoaQ0tGkX4A1nZo6068YWKDJGt/giyqa2QOb9uTMJox1mn+BA= X-Received: by 2002:a05:6808:15a8:b0:3eb:483f:978f with SMTP id 5614622812f47-3f323b6ec81mr17760451b6e.32.1738686230496; Tue, 04 Feb 2025 08:23:50 -0800 (PST) MIME-Version: 1.0 Reply-To: henning.garus@gmail.com From: Henning Garus Date: Tue, 4 Feb 2025 17:23:39 +0100 X-Gm-Features: AWEUYZnE2J5zlGXxy_ztpaOGAc6n3lliUq688zsUZ9iPYpu5fKsBOIGectPFZnw Message-ID: Subject: Index usage with differing string types To: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000251028062d536f1a" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000251028062d536f1a Content-Type: text/plain; charset="UTF-8" Hi, I stumbled upon this behaviour when digging into the performance of some merge statements generated by hibernate. Looking at different String types (varchar, text and bpchar) in some cases an index is used when the index type differs from the type in the query, in some cases it isn't used. Given a table with an index on a bpchar column: create table test (id bpchar(8) primary key); Both of the following queries use the index: explain select * from test where id = 'foo'::bpachar(3); explain select * from test where id = 'foo'::varchar; However when the String is cast to text the index isn't used: explain select * from test where id = 'foo'::text; This behavior seems to be consistent across postgres 12, 16 and 17. I find it surprising that the cast to varchar behaves differently than the cast to text, is this intended behaviour? Cheers Henning --000000000000251028062d536f1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I stumbled upon this behaviour when= digging into the performance of some merge statements generated by hiberna= te.

Looking at different String types (varchar, te= xt and bpchar) in some cases an index is used when the index type differs f= rom the type in the query, in some cases it isn't used.

<= /div>
Given a table with an index on a bpchar column:

create=C2=A0table test (id bpchar(8) primary key);

Both of the following queries use the index:

<= div>explain select * from test where id =3D 'foo'::bpachar(3);
explain select * from test where id =3D 'foo'::varchar;<= /div>

However when the String is cast to text the index = isn't used:

explain select * from test where i= d =3D 'foo'::text;

This behavior seems to = be consistent across postgres 12, 16 and 17.

I fin= d it surprising that the cast to varchar behaves differently than the cast = to text, is this intended behaviour?

Cheers
<= div>=C2=A0 Henning

--000000000000251028062d536f1a--