Re: BRIN minmax multi - incorrect distance for infinite timestamp/date - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: BRIN minmax multi - incorrect distance for infinite timestamp/date
Date
Msg-id 21465bdd-5b6d-6071-aa89-ce77e6f3cdb1@enterprisedb.com
Whole thread Raw
In response to Re: BRIN minmax multi - incorrect distance for infinite timestamp/date  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List pgsql-hackers

On 10/18/23 12:13, Dean Rasheed wrote:
> On Tue, 17 Oct 2023 at 21:25, Tomas Vondra
> <tomas.vondra@enterprisedb.com> wrote:
>>
>> Here's a couple cleaned-up patches fixing the various discussed here.
>> I've tried to always add a regression test demonstrating the issue
>> first, and then fix it in the next patch.
>>
> 
> This looks good to me.
> 
>> 2) incorrect subtraction in distance for date values (0003)
>>
>> All the problems except "2" have been discussed earlier, but this seems
>> a bit more serious than the other issues, as it's easier to hit. It
>> subtracts the values in the opposite order (smaller - larger), so the
>> distances are negated. Which means we actually merge the values from the
>> most distant ones, and thus are "guaranteed" to build very a very
>> inefficient summary.
>>
> 
> Yeah, that's not good. Amusingly this accidentally made infinite dates
> behave correctly, since they were distance 0 away from anything else,
> which was larger than all the other negative distances! But yes, that
> needed fixing properly.
> 

Right. Apparently two wrongs can make a right, after all ;-)


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Query execution in Perl TAP tests needs work
Next
From: David Steele
Date:
Subject: Re: Rename backup_label to recovery_control