Horton

Thread

Commits

  1. btree_gin: Fix calculation of leftmost interval value.

  1. btree_gin: Incorrect leftmost interval value

    Dean Rasheed <dean.a.rasheed@gmail.com> — 2023-10-27T09:26:53Z

    In contrib/btree_gin, leftmostvalue_interval() does this:

leftmostvalue_interval(void)
{
    Interval   *v = palloc(sizeof(Interval));

    v->time = DT_NOBEGIN;
    v->day = 0;
    v->month = 0;
    return IntervalPGetDatum(v);
}

which is a long way short of the minimum possible interval value.

As a result, a < or <= query using a GIN index on an interval column
may miss values. For example:

CREATE EXTENSION btree_gin;
CREATE TABLE foo (a interval);
INSERT INTO foo VALUES ('-1000000 years');
CREATE INDEX foo_idx ON foo USING gin (a);

SET enable_seqscan = off;
SELECT * FROM foo WHERE a < '1 year';
 a
---
(0 rows)

Attached is a patch fixing this by setting all the fields to their
minimum values, which is guaranteed to be less than any other
interval.

Note that this doesn't affect the contents of the index itself, so
reindexing is not necessary.

Regards,
Dean

  2. Re: btree_gin: Incorrect leftmost interval value

    Heikki Linnakangas <hlinnaka@iki.fi> — 2023-10-27T12:42:52Z

    On 27/10/2023 12:26, Dean Rasheed wrote:
> In contrib/btree_gin, leftmostvalue_interval() does this:
> 
> leftmostvalue_interval(void)
> {
>      Interval   *v = palloc(sizeof(Interval));
> 
>      v->time = DT_NOBEGIN;
>      v->day = 0;
>      v->month = 0;
>      return IntervalPGetDatum(v);
> }
> 
> which is a long way short of the minimum possible interval value.

Good catch!

> Attached is a patch fixing this by setting all the fields to their
> minimum values, which is guaranteed to be less than any other
> interval.

LGTM. I wish extractQuery could return "leftmost" more explicitly, so 
that we didn't need to construct these leftmost values. But I don't 
think that's supported by the current extractQuery interface.

-- 
Heikki Linnakangas
Neon (https://neon.tech)

  3. Re: btree_gin: Incorrect leftmost interval value

    Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2023-10-27T12:56:14Z

    On Fri, Oct 27, 2023 at 2:57 PM Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>
> In contrib/btree_gin, leftmostvalue_interval() does this:
>
> leftmostvalue_interval(void)
> {
>     Interval   *v = palloc(sizeof(Interval));
>
>     v->time = DT_NOBEGIN;
>     v->day = 0;
>     v->month = 0;
>     return IntervalPGetDatum(v);
> }
>
> which is a long way short of the minimum possible interval value.
>
> As a result, a < or <= query using a GIN index on an interval column
> may miss values. For example:
>
> CREATE EXTENSION btree_gin;
> CREATE TABLE foo (a interval);
> INSERT INTO foo VALUES ('-1000000 years');
> CREATE INDEX foo_idx ON foo USING gin (a);
>
> SET enable_seqscan = off;
> SELECT * FROM foo WHERE a < '1 year';
>  a
> ---
> (0 rows)
>
> Attached is a patch fixing this by setting all the fields to their
> minimum values, which is guaranteed to be less than any other
> interval.

Should we change this to call INTERVAL_NOBEGIN() to be added by
infinite interval patches? It's the same effect but looks similar to
leftmostvalue_timestamp/float8 etc. It will need to wait for the
infinite interval patches to commit but I guess, the wait won't be too
long and the outcome will be better. I can include this change in
those patches.

-- 
Best Wishes,
Ashutosh Bapat

  4. Re: btree_gin: Incorrect leftmost interval value

    Dean Rasheed <dean.a.rasheed@gmail.com> — 2023-10-27T13:05:21Z

    On Fri, 27 Oct 2023 at 13:56, Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> Should we change this to call INTERVAL_NOBEGIN() to be added by
> infinite interval patches?
>

Given that this is a bug that can lead to incorrect query results, I
plan to back-patch it, and INTERVAL_NOBEGIN() wouldn't make sense in
back-branches that don't have infinite intervals.

Regards,
Dean

  5. Re: btree_gin: Incorrect leftmost interval value

    Tom Lane <tgl@sss.pgh.pa.us> — 2023-10-27T14:27:44Z

    Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> On Fri, 27 Oct 2023 at 13:56, Ashutosh Bapat
> <ashutosh.bapat.oss@gmail.com> wrote:
>> Should we change this to call INTERVAL_NOBEGIN() to be added by
>> infinite interval patches?

> Given that this is a bug that can lead to incorrect query results, I
> plan to back-patch it, and INTERVAL_NOBEGIN() wouldn't make sense in
> back-branches that don't have infinite intervals.

Agreed.  When/if the infinite interval patch lands, it could update
this function to use the macro.

			regards, tom lane