| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Nitin Motiani <nitinmotiani(at)google(dot)com> |
| Cc: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>, alpkeles99(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19761: btree_gist: "cannot subtract infinite dates" when inserting 'infinity' into a GiST index on date |
| Date: | 2026-10-26 16:10:46 |
| Message-ID: | 638642.1793031046@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Nitin Motiani <nitinmotiani(at)google(dot)com> writes:
> Thanks for the review, Dilip. I'm attaching the v2 patch which makes
> the change in date_dist also.
I think this is not there yet. An important behavior of the
corresponding code for float8 (float_penalty_num_impl()) is that
it makes the distance between two same-sign infinity values be zero,
not infinity. This is mathematically wrong but we must do it for
indexing purposes, else inserting multiple infinities will end up
splitting each infinity onto its own index page when we want all
identical infinities to pack onto as few index pages as possible.
BTW, while checking this I happened to notice that
gbt_float8_dist has a variant of the same problem:
r = arg1 - arg2;
if (unlikely(isinf(r)) && !isinf(arg1) && !isinf(arg2))
float_overflow_error();
I don't think we want an error thrown there either;
returning the infinite distance (or DBL_MAX?) seems better.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2026-10-26 16:58:54 | BUG #19799: Self-join elimination: "failed to build any 3-way joins" with LATERAL |
| Previous Message | Manu | 2026-10-26 15:41:19 | Re: BUG #19760: CLUSTER loses a row the transaction inserted and then updated in a rolled-back subtransaction |