Re: index not used for bigint without explicit cast

From: "Sam(dot)Mesh" <Sam(dot)Mesh(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: index not used for bigint without explicit cast
Date: 2023-01-18 21:43:43
Message-ID: CACi6F2kMuEM8jnaXPmWrAKzdnGkyvA+9q1x6bh7sPrOzNRw_hw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Peter, thank you for clarification.
Could you please double check the following reasoning based on
https://www.postgresql.org/docs/current/btree-behavior.html?
- Index search by bigint column requires conversion of limiting
expressions to bigint type.
- Conversion from number(19,0) to bigint may cause overflow.
- So, index search is not possible.

On Tue, Jan 17, 2023 at 5:56 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2023-01-18 22:33:15 BUG #17753: pg_dump --if-exists bug
Previous Message Philip Semanchuk 2023-01-18 16:09:38 Re: IN clause behaving badly with missing comma and line break