Re: [HACKERS] compress method for spgist - 2

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: [HACKERS] compress method for spgist - 2
Дата
Msg-id CAPpHfdsAruXqE80v_crv=du4GoUqWgx55gXR05ZAhyRp4kxGBA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] compress method for spgist - 2  (Darafei "Komяpa" Praliaskouski <me@komzpa.net>)
Ответы Re: [HACKERS] compress method for spgist - 2  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] compress method for spgist - 2  (Nikita Glukhov <n.gluhov@postgrespro.ru>)
Список pgsql-hackers
On Thu, Sep 21, 2017 at 2:06 AM, Darafei "Komяpa" Praliaskouski <me@komzpa.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Windows warnings from VS 2017
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Windows warnings from VS 2017