On Sat, Feb 1, 2014 at 7:50 AM, Bruce Momjian wrote:
>
> Where are we on this?
I found myself to have empty draft letter from November with new version of
patch attached. I'll return here when we have some solution in gin fast
scan challenge.
--
With best regards,
Alexander Korotkov.
Where are we on this?
---
On Fri, Nov 8, 2013 at 01:38:28PM -0500, Tom Lane wrote:
> Alexander Korotkov writes:
> > I wrote attached patch by following principles:
> > 1) NaN coordinates shouldn't crash or hang GiST.
> > 2
Alexander Korotkov writes:
> I wrote attached patch by following principles:
> 1) NaN coordinates shouldn't crash or hang GiST.
> 2) NaN coordinates should be processed in GiST index scan like in
> sequential scan.
> 3) NaN coordinates shouldn't lead to significant slowdown.
I looked at this patc
Alexander Korotkov writes:
>> Thanks, Andrew! Good spot.
>> I didn't examine order by operators for work with NaNs.
>> I think this time problem is in GiST itself rather than in opclass. I'm
>> going to fix it in a separate patch.
> Attached patch fixes knn GiST behaviour with NaN. It makes RB-tr
On Tue, Sep 17, 2013 at 5:04 PM, Alexander Korotkov wrote:
> On Mon, Sep 16, 2013 at 4:13 PM, Andrew Gierth <
> and...@tao11.riddles.org.uk> wrote:
>
>> > "Alexander" == Alexander Korotkov writes:
>>
>> Alexander> 2) NaN coordinates should be processed in GiST index scan
>> Alexander> like
On Mon, Sep 16, 2013 at 4:13 PM, Andrew Gierth
wrote:
> > "Alexander" == Alexander Korotkov writes:
>
> Alexander> 2) NaN coordinates should be processed in GiST index scan
> Alexander> like in sequential scan.
>
> postgres=# select * from pts order by a <-> '(0,0)' limit 10;
> a
>
> "Alexander" == Alexander Korotkov writes:
Alexander> 2) NaN coordinates should be processed in GiST index scan
Alexander> like in sequential scan.
postgres=# select * from pts order by a <-> '(0,0)' limit 10;
a
--
(1,1)
(7,nan)
(9,nan)
(11,nan)
(4,nan)
(nan,6)
(2,
On Sat, Sep 7, 2013 at 1:47 AM, Tom Lane wrote:
> Alexander Korotkov writes:
> > PostGIS spotted that picksplit algorithm freezes in infinite loop when
> > dealing with nan values. I discovered same bug is present in core
> > opclasses. Attached patch fixes this issue interpreting nan as value
>
Alexander Korotkov writes:
> PostGIS spotted that picksplit algorithm freezes in infinite loop when
> dealing with nan values. I discovered same bug is present in core
> opclasses. Attached patch fixes this issue interpreting nan as value
> greater than infinity like btree comparison function does
Hackers,
PostGIS spotted that picksplit algorithm freezes in infinite loop when
dealing with nan values. I discovered same bug is present in core
opclasses. Attached patch fixes this issue interpreting nan as value
greater than infinity like btree comparison function does.
This patch contain copy
10 matches
Mail list logo
