Re: compress method for spgist - 2

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Darafei Komяpa Praliaskouski <me(at)komzpa(dot)net>
Cc: Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Fedor Sigaev <teodor(at)sigaev(dot)ru>
Subject: Re: compress method for spgist - 2
Date: 2017-09-20 23:27:50
Message-ID: CAPpHfdsAruXqE80v_crv=du4GoUqWgx55gXR05ZAhyRp4kxGBA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 21, 2017 at 2:06 AM, Darafei "Komяpa" Praliaskouski <
me(at)komzpa(dot)net> wrote:

> It is possible for bbox->low.x to be NaN when circle->center.x is and
>> circle->radius are both +Infinity.
>>
>
> What is rationale behind this circle?
>

I would prefer to rather forbid any geometries with infs and nans.
However, then upgrade process will suffer. User with such geometries would
get errors during dump/restore, pg_upgraded instances would still contain
invalid values...

> It seems to me that any circle with radius of any Infinity should become a
> [-Infinity .. Infinity, -Infinity .. Infinity] box.Then you won't have
> NaNs, and index structure shouldn't be broken.
>

We probably should produce [-Infinity .. Infinity, -Infinity .. Infinity]
box for any geometry containing inf or nan. That MBR would be founded for
any query, saying: "index can't help you for this kind value, only recheck
can deal with that". Therefore, we would at least guarantee that results
of sequential scan and index scan are the same.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-09-20 23:32:02 Re: Windows warnings from VS 2017
Previous Message Michael Paquier 2017-09-20 23:27:15 Re: Windows warnings from VS 2017