From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Korotkov <aekorotkov@gmail.com>
cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
        Alexander Law <exclusion@gmail.com>
Subject: Re: BUG #17302: gist index prevents insertion of some data
In-reply-to: 
 <CAPpHfdv4YHbQvo2VhAdCv7SAQtEP29CbRPJyF8z9a92ZQ=kFpA@mail.gmail.com>
References: <17302-dea8025c932a92f1@postgresql.org>
 <CAPpHfdv4YHbQvo2VhAdCv7SAQtEP29CbRPJyF8z9a92ZQ=kFpA@mail.gmail.com>
Comments: In-reply-to Alexander Korotkov <aekorotkov@gmail.com>
	message dated "Thu, 02 Dec 2021 01:08:27 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1999381.1638396843.1@sss.pgh.pa.us>
Date: Wed, 01 Dec 2021 17:14:03 -0500
Message-ID: <1999382.1638396843@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1999382.1638396843%40sss.pgh.pa.us>
Precedence: bulk

Alexander Korotkov <aekorotkov@gmail.com> writes:
> I think losing precision in the gist penalty is generally OK.  Thus,
> it shouldn't be a problem to round a very small value as zero.

Check.

> Probably, we could even tolerate overflow in the gist penalty.

As long as overflow -> infinity, yeah I think so.  Seems like it
was a mistake to insert the overflow-testing functions in this code
at all, and we should simplify it down to plain C addition/subtraction/
multiplication.

			regards, tom lane