| From: | Darafei "Komяpa" Praliaskouski <me(at)komzpa(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Alexander Korotkov <aekorotkov(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Alexander Law <exclusion(at)gmail(dot)com> |
| Subject: | Re: BUG #17302: gist index prevents insertion of some data |
| Date: | 2021-12-02 06:02:09 |
| Message-ID: | CAC8Q8tLrGsfb1s+rFy0ZHe6rEJ4zLStrwVFfG83U1NDFAbGC0A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
On Thu, Dec 2, 2021 at 1:14 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alexander Korotkov <aekorotkov(at)gmail(dot)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.
>
The underflow should not throw an interrupting exception ever, even on
plain SQL-level calculations.
The code to implement was added in error by a series of misunderstandings
and gets in the way of simple things too often. I dug into the history here:
>
> regards, tom lane
>
>
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ian R. Campbell | 2021-12-02 16:24:42 | Inconsistent cast to "char" |
| Previous Message | PG Bug reporting form | 2021-12-02 05:24:23 | BUG #17307: Performance deviation between the multiple iterations (NOPM & TPM values). |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Himanshu Upadhyaya | 2021-12-02 06:07:47 | Re: SQL/JSON: functions |
| Previous Message | Amit Kapila | 2021-12-02 05:27:41 | Re: pg_get_publication_tables() output duplicate relid |