Re: compress method for spgist - 2

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: compress method for spgist - 2

Teodor Sigaev
 > 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 in this case, see begining of
spgdoinsert()


 > Could you find some use for this in one of the built-in or contrib
 > types? Just to have something that exercises it as part of the
 > regression suite. How about creating an opclass for the built-in polygon
 > type that stores the bounding box, like the PostGIS guys are doing?

Will try, but I don't have nice idea. Polygon opclass will have awful
performance until PostGIS guys show the tree structure.

 > The documentation needs to be updated.
Added.

--
Teodor Sigaev                                   E-mail: [hidden email]
                                                    WWW: http://www.sigaev.ru/


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

spgist_compress_method-3.patch.gz (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: compress method for spgist - 2

Heikki Linnakangas-6
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 config method */
>
>         SpGistTypeDesc attType;         /* type of input data and leaf values */
>         SpGistTypeDesc attPrefixType;           /* type of inner-tuple prefix values */
>         SpGistTypeDesc attLabelType;    /* type of node label values */
>
>         SpGistLUPCache lastUsedPages;           /* local storage of last-used info */
> } SpGistCache;
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 datum? In freeScanStackEntry, we assume that
att[Leaf]Type is the datatype for reconstructedValue, but I believe
assume elsewhere that reconstructedValue is of the same data type as the
input. At least if the opclass supports index-only scans.

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 something like that.

Attached is a patch with the kibitzing I did so far.

- Heikki



--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

spgist_compress_method-4-heikki.patch (13K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: compress method for spgist - 2

Teodor Sigaev
> 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 datum? In
> freeScanStackEntry, we assume that att[Leaf]Type is the datatype for
> reconstructedValue, but I believe assume elsewhere that reconstructedValue is of
> the same data type as the input. At least if the opclass supports index-only scans.


Agree with rename. I doubt that there is a real-world example of datatype which
can be a) effectivly compressed and b) restored to original form. If so, why
don't store it in compressed state in database? In GiST all compress methods
uses one-way compress. In PostGIS example, polygons are "compressed" into
bounding box, and, obviously, they cannot be restored.

>
> 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 something like that.

I suppose that compress and reconstruct are mutual exclusive options.

--
Teodor Sigaev                                   E-mail: [hidden email]
                                                    WWW: http://www.sigaev.ru/


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: compress method for spgist - 2

Heikki Linnakangas-6
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 something like that.
> I suppose that compress and reconstruct are mutual exclusive options.

I would rather not assume that. You might well want to store something
in the leaf nodes that's different from the original Datum, but
nevertheless contains enough information to reconstruct the original Datum.

- Heikki



--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: compress method for spgist - 2

Michael Paquier
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 ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: compress method for spgist - 2

Heikki Linnakangas-6
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, "btree_gin and ranges".
I pushed the refactoring patch I posted to that thread
(http://www.postgresql.org/message-id/54983CF2.80605@...)
already. I haven't proposed any refactoring related to spgist.

- Heikki


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: compress method for spgist - 2

Teodor Sigaev
In reply to this post by Heikki Linnakangas-6
> 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 datum? In

Done. Now there is separate attType and attLeafType which describe input/output
and leaf types.


--
Teodor Sigaev                                   E-mail: [hidden email]
                                                    WWW: http://www.sigaev.ru/


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

spgist_compress_method-5.patch.gz (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: compress method for spgist - 2

Heikki Linnakangas-6
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 & replace, but what about the reconstructed datum? In
>
> Done. Now there is separate attType and attLeafType which describe input/output
> and leaf types.

Thanks.

Did you try finding a use case for this patch in one of the built-in or
contrib datatypes? That would allow writing a regression test for this.

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.2080406@...). Any
idea how would that work?

- Heikki


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: compress method for spgist - 2

Paul Ramsey
On Wed, Feb 25, 2015 at 6:13 AM, Heikki Linnakangas
<[hidden email]> 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.2080406@...). Any idea
> how would that work?

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
sufficiently rare compared to the overall volume of data, to not be an
issue. Oddly enough this big hammer has worked in other
implementations at least passable well
(https://github.com/mapserver/mapserver/blob/branch-7-0/maptree.c#L261)

P.


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: compress method for spgist - 2

Heikki Linnakangas
On 03/04/2015 06:58 PM, Paul Ramsey wrote:

> On Wed, Feb 25, 2015 at 6:13 AM, Heikki Linnakangas
> <[hidden email]> 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.2080406@...). Any idea
>> how would that work?
>
> 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
> sufficiently rare compared to the overall volume of data, to not be an
> issue. Oddly enough this big hammer has worked in other
> implementations at least passable well
> (https://github.com/mapserver/mapserver/blob/branch-7-0/maptree.c#L261)

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 - which can overlap - in an SP-GiST index? And
how does the compress method help with that?

- Heikki



--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: compress method for spgist - 2

Teodor Sigaev
>> 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 - which can overlap - in an SP-GiST index? And how does the compress
> method help with that?

I believe if we found a way to index boxes then we will need a compress method
to build index over polygons.

BTW, we are working on investigation a index structure for box where 2d-box is
treated as 4d-point.


--
Teodor Sigaev                                   E-mail: [hidden email]
                                                    WWW: http://www.sigaev.ru/


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: compress method for spgist - 2

Michael Paquier
On Thu, Jul 23, 2015 at 6:18 PM, Teodor Sigaev <[hidden email]> 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 partitions the space into non-overlapping sections. How can you
>> store
>> polygons - which can overlap - in an SP-GiST index? And how does the
>> compress
>> method help with that?
>
>
> I believe if we found a way to index boxes then we will need a compress
> method to build index over polygons.
>
> BTW, we are working on investigation a index structure for box where 2d-box
> is treated as 4d-point.

There has been no activity on this patch for some time now, and a new
patch version has not been submitted, so I am marking it as return
with feedback.
--
Michael


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: compress method for spgist - 2

Alexander Korotkov-3
On Tue, Aug 25, 2015 at 4:05 PM, Michael Paquier <[hidden email]> wrote:
On Thu, Jul 23, 2015 at 6:18 PM, Teodor Sigaev <[hidden email]> 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 partitions the space into non-overlapping sections. How can you
>> store
>> polygons - which can overlap - in an SP-GiST index? And how does the
>> compress
>> method help with that?
>
>
> I believe if we found a way to index boxes then we will need a compress
> method to build index over polygons.
>
> BTW, we are working on investigation a index structure for box where 2d-box
> is treated as 4d-point.

There has been no activity on this patch for some time now, and a new
patch version has not been submitted, so I am marking it as return
with feedback.

There is interest to this patch from PostGIS users.  It would be nice to pickup this patch.
AFAICS, the progress on this patch was suspended because we have no example for SP-GiST compress method in core/contrib.
However, now we have acdf2a8b committed with 2d to 4d indexing of boxes using SP-GiST.  So, extending this 2d to 4d approach to polygons would be good example of SP-GiST compress method in core.  Would anyone be volunteering for writing such patch?
If nobody, then I could do it....

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company 
Reply | Threaded
Open this post in threaded view
|

Re: compress method for spgist - 2

Alexander Korotkov-3
On Mon, Sep 18, 2017 at 6:21 PM, Alexander Korotkov <[hidden email]> wrote:
On Tue, Aug 25, 2015 at 4:05 PM, Michael Paquier <[hidden email]> wrote:
On Thu, Jul 23, 2015 at 6:18 PM, Teodor Sigaev <[hidden email]> 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 partitions the space into non-overlapping sections. How can you
>> store
>> polygons - which can overlap - in an SP-GiST index? And how does the
>> compress
>> method help with that?
>
>
> I believe if we found a way to index boxes then we will need a compress
> method to build index over polygons.
>
> BTW, we are working on investigation a index structure for box where 2d-box
> is treated as 4d-point.

There has been no activity on this patch for some time now, and a new
patch version has not been submitted, so I am marking it as return
with feedback.

There is interest to this patch from PostGIS users.  It would be nice to pickup this patch.
AFAICS, the progress on this patch was suspended because we have no example for SP-GiST compress method in core/contrib.
However, now we have acdf2a8b committed with 2d to 4d indexing of boxes using SP-GiST.  So, extending this 2d to 4d approach to polygons would be good example of SP-GiST compress method in core.  Would anyone be volunteering for writing such patch?
If nobody, then I could do it....

Nobody answered yet.  And I decided to nail down this long term issue.  Please, find following attached patches.

0001-spgist-compress-method-6.patch

Patch with SP-GiST compress method rebased on current master.  Index AM interface was changed since that time.  I've added validation for compress method: it validates input and output types of compress method.  That required to call config method before.  That is controversial solution.  In particular, no collation is provided in config method call.  It would be weird if collation could affect data types in SP-GiST config method output, but anyway...

0002-spgist-circle-polygon-6.patch

This patch provides example of SP-GiST compress method usage.  It adds SP-GiST indexing for circles and polygons using mapping of their bounding boxes to 4d.  This patch is based on prior work by Nikita Glukhov for SP-GiST KNN.

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


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

0001-spgist-compress-method-6.patch (24K) Download Attachment
0002-spgist-circle-polygon-6.patch (58K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: compress method for spgist - 2

Darafei Praliaskouski
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 PostGIS can benefit from SP-GiST infrastructure.

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.
 * There are tests for infinities in circles, but checks are for NaNs.
 * It seems to me that circle can be implemented without recheck, by making direct exact calculations.
How about removing circle from the scope of this patch, so it is smaller and cleaner?
--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: compress method for spgist - 2

Alexander Korotkov
On Wed, Sep 20, 2017 at 10:00 PM, Darafei Praliaskouski <[hidden email]> 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

Hi,

I like the SP-GiST part of the patch. Looking forward to it, so PostGIS can benefit from SP-GiST infrastructure.

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.
 * There are tests for infinities in circles, but checks are for NaNs.

This code was migrated from original patch by Nikita.  I can assume he means that nan should be treated as greatest possible floating point value (like float4_cmp_internal() does).  However, our current implementation of geometrical datatypes don't correctly handles all the combinations of infs as nans.  Most of code was written without taking infs and nans into account.  Also, I'm not sure if this code fixes all possible issues with infs and nans in SP-GiST opclass for circles.  This is why I'm going to remove nans handling from this place.
 
 * It seems to me that circle can be implemented without recheck, by making direct exact calculations.

Right.  Holding circles in the leafs instead of bounding boxes would both allow exact calculations and take less space.
 
How about removing circle from the scope of this patch, so it is smaller and cleaner?

Good point.  Polygons are enough for compress function example.  Opclass for circles could be submitted as separate patch.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company 
Reply | Threaded
Open this post in threaded view
|

Re: compress method for spgist - 2

Tom Lane-2
In reply to this post by Darafei Praliaskouski
Darafei Praliaskouski <[hidden email]> 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, so I went and looked:

+ bbox->high.x = circle->center.x + circle->radius;
+ bbox->low.x = circle->center.x - circle->radius;
+ bbox->high.y = circle->center.y + circle->radius;
+ bbox->low.y = circle->center.y - circle->radius;
+
+ if (isnan(bbox->low.x))
+ {
+ double tmp = bbox->low.x;
+ bbox->low.x = bbox->high.x;
+ bbox->high.x = tmp;
+ }

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 circle->radius is a
NaN, in which case bbox->high.x would also have been computed as a NaN,
making the swap entirely useless.  Likewise for the Y case.  There may be
something useful to do about NaNs here, but this doesn't seem like it.

> How about removing circle from the scope of this patch, so it is smaller and cleaner?

Neither of those patches would be particularly large, and since they'd need
to touch adjacent code in some places, the diffs wouldn't be independent.
I think splitting them is just make-work.

                        regards, tom lane


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|

Re: compress method for spgist - 2

Alexander Korotkov
On Wed, Sep 20, 2017 at 11:07 PM, Tom Lane <[hidden email]> wrote:
Darafei Praliaskouski <[hidden email]> 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, so I went and looked:

+       bbox->high.x = circle->center.x + circle->radius;
+       bbox->low.x = circle->center.x - circle->radius;
+       bbox->high.y = circle->center.y + circle->radius;
+       bbox->low.y = circle->center.y - circle->radius;
+
+       if (isnan(bbox->low.x))
+       {
+               double tmp = bbox->low.x;
+               bbox->low.x = bbox->high.x;
+               bbox->high.x = tmp;
+       }

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 circle->radius is a
NaN, in which case bbox->high.x would also have been computed as a NaN,
making the swap entirely useless.  Likewise for the Y case.  There may be
something useful to do about NaNs here, but this doesn't seem like it.
 
Yeah, +1.

> How about removing circle from the scope of this patch, so it is smaller and cleaner?

Neither of those patches would be particularly large, and since they'd need
to touch adjacent code in some places, the diffs wouldn't be independent.
I think splitting them is just make-work.

I've extracted polygon opclass into separate patch (attached).  I'll rework and resubmit circle patch later.
I'm not particularly sure that polygon.sql is a good place for testing sp-gist opclass for polygons...  But we've already done so for box.sql.

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


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

0001-spgist-compress-method-7.patch (24K) Download Attachment
0002-spgist-polygon-7.patch (36K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: compress method for spgist - 2

Nikita Glukhov

On 20.09.2017 23:19, Alexander Korotkov wrote:

On Wed, Sep 20, 2017 at 11:07 PM, Tom Lane <[hidden email]> wrote:
Darafei Praliaskouski <[hidden email]> 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, so I went and looked:

+       bbox->high.x = circle->center.x + circle->radius;
+       bbox->low.x = circle->center.x - circle->radius;
+       bbox->high.y = circle->center.y + circle->radius;
+       bbox->low.y = circle->center.y - circle->radius;
+
+       if (isnan(bbox->low.x))
+       {
+               double tmp = bbox->low.x;
+               bbox->low.x = bbox->high.x;
+               bbox->high.x = tmp;
+       }

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 circle->radius is a
NaN, in which case bbox->high.x would also have been computed as a NaN,
making the swap entirely useless.  Likewise for the Y case.  There may be
something useful to do about NaNs here, but this doesn't seem like it.
 
Yeah, +1.


It is possible for bbox->low.x to be NaN when circle->center.x is and
circle->radius are both +Infinity.  Without this float-order-preserving swapping
one regression test for KNN with ORDER BY index will be totally broken (you can
try it: https://github.com/glukhovn/postgres/tree/knn).  Unfortunately, I do not
remember exactly why, but most likely because of the incorrect index structure.

--
Nikita Glukhov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Reply | Threaded
Open this post in threaded view
|

Re: compress method for spgist - 2

Tom Lane-2
Nikita Glukhov <[hidden email]> writes:
> On 20.09.2017 23:19, Alexander Korotkov wrote:
>> On Wed, Sep 20, 2017 at 11:07 PM, Tom Lane <[hidden email]
>> <mailto:[hidden email]>> 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
>>> circle->radius is a NaN, in which case bbox->high.x would also have been computed as a NaN,
>>> making the swap entirely useless.

> It is possible for bbox->low.x to be NaN when circle->center.x is and
> circle->radius are both +Infinity.  Without this float-order-preserving
> swapping
> one regression test for KNN with ORDER BY index will be totally broken
> (you can
> try it: https://github.com/glukhovn/postgres/tree/knn).

If that's the reasoning, not having a comment explaining it is
inexcusable.  Do you really think people will understand what
the code is doing?

                        regards, tom lane


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
12
Previous Thread Next Thread