Skip site navigation (1) Skip section navigation (2)

Re: Incorrect behaviour when using a GiST index on points

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Oleg Bartunov <obartunov(at)gmail(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Incorrect behaviour when using a GiST index on points
Date: 2012-11-02 17:01:17
Message-ID: CAPpHfdv3p8pOU5-uy7swHXqve8EwHvbCs8Xwmjf-CXGDQbyzbQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Nov 2, 2012 at 4:46 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:

> On Fri, Nov 02, 2012 at 04:05:30PM +0400, Alexander Korotkov wrote:
> > On Thu, Oct 18, 2012 at 11:18 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
>
> > > > --- 1339,1356 ----
> > > >                       *recheck = false;
> > > >                       break;
> > > >               case BoxStrategyNumberGroup:
> > > > !                     /*
> > > > !                      * This code repeats logic of on_ob which uses
> > > simple comparison
> > > > !                      * rather than FP* functions.
> > > > !                      */
> > > > !                     query = PG_GETARG_BOX_P(1);
> > > > !                     key = DatumGetBoxP(entry->key);
> > > > !
> > > > !                     *recheck = false;
> > > > !                     result = key->high.x >= query->low.x &&
> > > > !                                      key->low.x <= query->high.x &&
> > > > !                                      key->high.y >= query->low.y &&
> > > > !                                      key->low.y <= query->high.y;
> > >
> > > For leaf entries, this correctly degenerates to on_pb().  For internal
> > > entries, it must, but does not, implement box_overlap().  (The fuzzy
> > > box_overlap() would be fine.)  I recommend making
> gist_point_consistent()'s
> > > treatment of boxes resemble its treatment of circles and polygons; that
> > > eases
> > > verifying their correctness.  Call gist_box_consistent.  Then, for leaf
> > > entries, call box_contain_pt().
> > >
> >
> > I have two objections on doing that:
> > 1) It's not evident for me that fuzzy comparison in internal pages is
> fine.
> > Obviously, it depends on data distribution. It's easy to provide an
> example
> > when fuzzy comparison will lead to significant performance degradation.
> > 2) With PolygonStrategyNumberGroup CircleStrategyNumberGroup it's faster
> to
> > do simple box comparison than doing calculation for exact circle and
> > especially polygon check. In this case previous filtering in leaf pages
> > looks reasonable. With BoxStrategyNumberGroup exact calculation is
> simpler
> > than gist_box_consistent.
>
> That's fair; I withdraw the recommendation to use gist_box_consistent().
>  It
> remains that the code here must somehow implement a box_overlap()-style
> calculation for internal pages.
>

Sorry, didn't understand this point. What exactly do you mean by
box_overlap()-style?

------
With best regards,
Alexander Korotkov.

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2012-11-02 17:31:54
Subject: Re: Synchronous commit not... synchronous?
Previous:From: Fujii MasaoDate: 2012-11-02 16:48:56
Subject: the number of pending entries in GIN index with FASTUPDATE=on

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group