Re: BRIN minmax multi - incorrect distance for infinite timestamp/date
От | Tomas Vondra |
---|---|
Тема | Re: BRIN minmax multi - incorrect distance for infinite timestamp/date |
Дата | |
Msg-id | 21465bdd-5b6d-6071-aa89-ce77e6f3cdb1@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: BRIN minmax multi - incorrect distance for infinite timestamp/date (Dean Rasheed <dean.a.rasheed@gmail.com>) |
Список | 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 по дате отправления: