From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | "Sam(dot)Mesh" <Sam(dot)Mesh(at)gmail(dot)com> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: index not used for bigint without explicit cast |
Date: | 2023-01-18 01:55:36 |
Message-ID: | CAH2-WzkUxnikXJ_MyYgeZWe=J-+xbMgV+MeyL-XayLgRn1dd4w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, Jan 17, 2023 at 5:44 PM Sam.Mesh <Sam(dot)Mesh(at)gmail(dot)com> wrote:
> The problem arrises with the other case, where the values from the table are to be converted to match the datatype of the query (i.e., we give numeric in query and the column is of bigint type). As Postgres can only cast a bigint to numeric, the only option it has is to convert every row in the table to numeric and then compare. Thus in this case, the index won’t be used.
> ***
>
> Probably, somebody knows the current state of this limitation?
Not all numeric values can be converted to int8 without loss of
precision. If it was allowed, it would create subtle problems. The
same is not true for (say) int4 and int8, which can be mixed in the
way that you would expect.
Internally, int4 and int8 are part of the same btree operator family,
and so follow certain rules which are described here:
https://www.postgresql.org/docs/current/btree-behavior.html
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2023-01-18 04:32:27 | Re: DROP DATABASE deadlocks with logical replication worker in PG 15.1 |
Previous Message | Sam.Mesh | 2023-01-18 01:43:37 | index not used for bigint without explicit cast |