Re: Incorrect behaviour when using a GiST index on points

On Sun, Nov 04, 2012 at 01:53:19AM +0400, Alexander Korotkov wrote:
> On Sat, Nov 3, 2012 at 4:23 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> > I was thrown off by your use of a different, albeit
> > mathematically
> > equivalent, algorithm from the one used in box_overlap(). Please don't do
> > that; either use box_overlap()'s algorithm here, or change box_overlap() to
> > use the shorter algorithm you have introduced. Formulating the same
> > calculation differently in related code is a recipe for confusion. (Then
> > again, perhaps the equivalence of the algorithms is obvious to everyone
> > entitled to travel within 1 km of the geometric type implementation.)
> >
>
> I've added comment for clarifying this situation.

Good enough.

> ! * This code repeats logic of on_ob which checks if point is

Typo: the function is on_pb().

> + -- Testing GiST indexes provides same behaviour as sequential scan
> + SET enable_seqscan TO false;
> + CREATE TABLE POINT_GIST_TBL(f1 point);
> + INSERT INTO POINT_GIST_TBL (SELECT '(0,0)' FROM generate_series(0,1000));
> + CREATE INDEX POINT_GIST_TBL_INDEX ON POINT_GIST_TBL USING gist (f1);
> + INSERT INTO POINT_GIST_TBL VALUES ('(0.0000009,0.0000009)');
> + SELECT COUNT(*) FROM POINT_GIST_TBL WHERE f1 ~= '(0.0000009,0.0000009)'::point;
> + SELECT COUNT(*) FROM POINT_GIST_TBL WHERE f1 <@ '(0.0000009,0.0000009),(0.0000009,0.0000009)'::box;
> + SELECT COUNT(*) FROM POINT_GIST_TBL WHERE f1 ~= '(0.0000018,0.0000018)'::point;

Do a "RESET enable_seqscan;" at the end. The omission has no consequence here
since these are the last commands of the test file.

Neither of those things are important enough to call for a new version; I'm
leaving the patch Ready for Committer.

Thanks,
nm