Re: [HACKERS] compress method for spgist - 2

On 21.09.2017 02:27, Alexander Korotkov wrote: On Thu, Sep 21, 2017 at 2:06 AM, Darafei "Komяpa" Praliaskouski mailto:m...@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 rational

Re: [HACKERS] compress method for spgist - 2

On Thu, Sep 21, 2017 at 3:14 AM, Tom Lane wrote: > Alexander Korotkov writes: > > On Thu, Sep 21, 2017 at 2:06 AM, Darafei "Komяpa" Praliaskouski < > >> It seems to me that any circle with radius of any Infinity should > become a > >> [-Infinity .. Infinity, -Infinity .. Infinity] box.Then you w

Re: [HACKERS] compress method for spgist - 2

Alexander Korotkov writes: > On Thu, Sep 21, 2017 at 2:06 AM, Darafei "Komяpa" Praliaskouski < > m...@komzpa.net> wrote: >> 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 geome

Re: [HACKERS] compress method for spgist - 2

On Thu, Sep 21, 2017 at 2:06 AM, Darafei "Komяpa" Praliaskouski < m...@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 wit

Re: [HACKERS] compress method for spgist - 2

=?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?= writes: > If it happens because NaN > Infinity, then the check should be not for > isnan, but for if (low>high){swap(high, low)}. Yeah, the same idea had occurred to me. It'd still need a comment, but at least it's slightly more apparent what w

Re: [HACKERS] compress method for spgist - 2

> > 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? 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

Re: [HACKERS] compress method for spgist - 2

Nikita Glukhov writes: > On 20.09.2017 23:19, Alexander Korotkov wrote: >> On Wed, Sep 20, 2017 at 11:07 PM, Tom Lane > > wrote: >>> Maybe I'm missing something, but it appears to me that it's >>> impossible for bbox->low.x to be NaN unless circle->center.x and/or >>> ci

Re: [HACKERS] compress method for spgist - 2

On 20.09.2017 23:19, Alexander Korotkov wrote: On Wed, Sep 20, 2017 at 11:07 PM, Tom Lane > wrote: Darafei Praliaskouski mailto:m...@komzpa.net>> writes: > I have some questions about the circles example though. >  * What is the reason for isnan check and

Re: [HACKERS] compress method for spgist - 2

On Wed, Sep 20, 2017 at 11:07 PM, Tom Lane wrote: > Darafei Praliaskouski writes: > > I have some questions about the circles example though. > > > * What is the reason for isnan check and swap of box ordinates for > circle? It wasn't in the code previously. > > I hadn't paid any attention to t

Re: [HACKERS] compress method for spgist - 2

Darafei Praliaskouski writes: > I have some questions about the circles example though. > * What is the reason for isnan check and swap of box ordinates for circle? > It wasn't in the code previously. I hadn't paid any attention to this patch previously, but this comment excited my curiosity,

Re: [HACKERS] compress method for spgist - 2

On Wed, Sep 20, 2017 at 10:00 PM, Darafei Praliaskouski wrote: > The following review has been posted through the commitfest application: > make installcheck-world: not tested > Implements feature: not tested > Spec compliant: not tested > Documentation:tested, passed

Re: [HACKERS] compress method for spgist - 2

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:tested, passed Hi, I like the SP-GiST part of the patch. Looking forward to it, so Post

Re: [HACKERS] compress method for spgist - 2

On Mon, Sep 18, 2017 at 6:21 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Tue, Aug 25, 2015 at 4:05 PM, Michael Paquier < > michael.paqu...@gmail.com> wrote: > >> On Thu, Jul 23, 2015 at 6:18 PM, Teodor Sigaev wrote: >> >>> Poorly, by hanging boxes that straddled dividing lines

Re: [HACKERS] compress method for spgist - 2

On Tue, Aug 25, 2015 at 4:05 PM, Michael Paquier wrote: > On Thu, Jul 23, 2015 at 6:18 PM, Teodor Sigaev wrote: > >>> Poorly, by hanging boxes that straddled dividing lines off the parent > >>> node in a big linear list. The hope would be that the case was > >> > >> Ok, I see, but that's not rea

Re: [HACKERS] compress method for spgist - 2

On Thu, Jul 23, 2015 at 6:18 PM, Teodor Sigaev wrote: >>> Poorly, by hanging boxes that straddled dividing lines off the parent >>> node in a big linear list. The hope would be that the case was >> >> Ok, I see, but that's not really what I was wondering. My question is >> this: >> SP-GiST partiti

Re: [HACKERS] compress method for spgist - 2

Poorly, by hanging boxes that straddled dividing lines off the parent node in a big linear list. The hope would be that the case was Ok, I see, but that's not really what I was wondering. My question is this: SP-GiST partitions the space into non-overlapping sections. How can you store polygons -

Re: [HACKERS] compress method for spgist - 2

On 03/04/2015 06:58 PM, Paul Ramsey wrote: On Wed, Feb 25, 2015 at 6:13 AM, Heikki Linnakangas wrote: In the original post on this, you mentioned that the PostGIS guys planned to use this to store polygons, as bounding boxes (http://www.postgresql.org/message-id/5447b3ff.2080...@sigaev.ru). Any

Re: [HACKERS] compress method for spgist

On Wed, Oct 22, 2014 at 05:41:19PM +0400, Teodor Sigaev wrote: > When we developed SP-GiST we missed analogue of GiST's compress > method. There was two reasons for that: lack of imagination to > imagine case with different types of indexed value and column, and > we didn't want call some method wh

Re: [HACKERS] compress method for spgist - 2

On Wed, Feb 25, 2015 at 6:13 AM, Heikki Linnakangas wrote: > In the original post on this, you mentioned that the PostGIS guys planned to > use this to store polygons, as bounding boxes > (http://www.postgresql.org/message-id/5447b3ff.2080...@sigaev.ru). Any idea > how would that work? Poorly, by

Re: [HACKERS] compress method for spgist - 2

On 02/13/2015 06:17 PM, Teodor Sigaev wrote: Now that the input data type and leaf data type can be different, which one is "attType"? It's the leaf data type, as the patch stands. I renamed that to attLeafType, and went fixing all the references to it. In most places it's just a matter of search

Re: [HACKERS] compress method for spgist - 2

Now that the input data type and leaf data type can be different, which one is "attType"? It's the leaf data type, as the patch stands. I renamed that to attLeafType, and went fixing all the references to it. In most places it's just a matter of search & replace, but what about the reconstructed d

Re: [HACKERS] compress method for spgist - 2

On 01/15/2015 09:28 AM, Michael Paquier wrote: Marking this patch as returned with feedback because it is waiting for input from the author for now a couple of weeks. Heikki, the refactoring patch has some value, are you planning to push it? I think you're mixing up with the other thread, "btre

Re: [HACKERS] compress method for spgist - 2

Marking this patch as returned with feedback because it is waiting for input from the author for now a couple of weeks. Heikki, the refactoring patch has some value, are you planning to push it? -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] compress method for spgist - 2

On 12/23/2014 03:02 PM, Teodor Sigaev wrote: >I think we'll need a separate SpGistTypeDesc for the input type. Or perhaps a >separate SpGistTypeDesc for the reconstructed value and an optional decompress >method to turn the reconstructedValue back into an actual reconstructed input >datum. Or som

Re: [HACKERS] compress method for spgist - 2

Now that the input data type and leaf data type can be different, which one is "attType"? It's the leaf data type, as the patch stands. I renamed that to attLeafType, and went fixing all the references to it. In most places it's just a matter of search & replace, but what about the reconstructed d

Re: [HACKERS] compress method for spgist - 2

On 12/16/2014 07:48 PM, Teodor Sigaev wrote: /* * This struct is what we actually keep in index->rd_amcache. It includes * static configuration information as well as the lastUsedPages cache. */ typedef struct SpGistCache { spgConfigOut config;/* filled in by opclass confi

Re: [HACKERS] compress method for spgist - 2

> For some datatypes, the compress method might be useful even if the leaf > type is the same as the column type. For example, you could allow > indexing text datums larger than the page size, with a compress function > that just truncates the input. Agree, and patch allows to use compress method

Re: [HACKERS] compress method for spgist - 2

On 12/01/2014 02:44 PM, Teodor Sigaev wrote: Initial message: http://www.postgresql.org/message-id/5447b3ff.2080...@sigaev.ru Second version fixes a forgotten changes in pg_am. + /* Get the information we need about each relevant datatypes */ + + if (OidIsValid(ca

[HACKERS] compress method for spgist - 2

Initial message: http://www.postgresql.org/message-id/5447b3ff.2080...@sigaev.ru Second version fixes a forgotten changes in pg_am. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ spgist

[HACKERS] compress method for spgist

When we developed SP-GiST we missed analogue of GiST's compress method. There was two reasons for that: lack of imagination to imagine case with different types of indexed value and column, and we didn't want call some method while index fit in one page. Some discussion on that http://www.postg