On 05/16/2015 12:42 AM, Jim Nasby wrote:
On 5/14/15 6:30 PM, Heikki Linnakangas wrote:
On 05/15/2015 02:28 AM, Heikki Linnakangas wrote:
I think this is now ready for committing, but I'm pretty tired now so
I'll read through this one more time in the morning, so that I won't
wake up to a red bu
On 5/14/15 6:30 PM, Heikki Linnakangas wrote:
On 05/15/2015 02:28 AM, Heikki Linnakangas wrote:
I think this is now ready for committing, but I'm pretty tired now so
I'll read through this one more time in the morning, so that I won't
wake up to a red buildfarm.
If anyone feels motivated to fi
On Fri, May 15, 2015 at 2:49 PM, Alexander Korotkov
wrote:
> On Fri, May 15, 2015 at 2:48 PM, Heikki Linnakangas
> wrote:
>
>> On 05/15/2015 11:31 AM, Alexander Korotkov wrote:
>>
>>> On Fri, May 15, 2015 at 2:30 AM, Heikki Linnakangas
>>> wrote:
>>>
>>> On 05/15/2015 02:28 AM, Heikki Linnakan
On Fri, May 15, 2015 at 02:48:29PM +0300, Heikki Linnakangas wrote:
> On 05/15/2015 11:31 AM, Alexander Korotkov wrote:
> >On Fri, May 15, 2015 at 2:30 AM, Heikki Linnakangas wrote:
> >
> >>On 05/15/2015 02:28 AM, Heikki Linnakangas wrote:
> >>
> >>>I think this is now ready for committing, but I'
On Fri, May 15, 2015 at 2:48 PM, Heikki Linnakangas wrote:
> On 05/15/2015 11:31 AM, Alexander Korotkov wrote:
>
>> On Fri, May 15, 2015 at 2:30 AM, Heikki Linnakangas
>> wrote:
>>
>> On 05/15/2015 02:28 AM, Heikki Linnakangas wrote:
>>>
>>> I think this is now ready for committing, but I'm pr
On 05/15/2015 11:31 AM, Alexander Korotkov wrote:
On Fri, May 15, 2015 at 2:30 AM, Heikki Linnakangas wrote:
On 05/15/2015 02:28 AM, Heikki Linnakangas wrote:
I think this is now ready for committing, but I'm pretty tired now so
I'll read through this one more time in the morning, so that I
On Fri, May 15, 2015 at 2:30 AM, Heikki Linnakangas wrote:
> On 05/15/2015 02:28 AM, Heikki Linnakangas wrote:
>
>> I think this is now ready for committing, but I'm pretty tired now so
>> I'll read through this one more time in the morning, so that I won't
>> wake up to a red buildfarm.
>>
>
> F
On 05/15/2015 02:28 AM, Heikki Linnakangas wrote:
I think this is now ready for committing, but I'm pretty tired now so
I'll read through this one more time in the morning, so that I won't
wake up to a red buildfarm.
Forgot to attach the latest patch, here you go.
- Heikki
From df00d9c972a760e
On 05/14/2015 01:43 PM, Alexander Korotkov wrote:
On Wed, May 13, 2015 at 10:17 PM, Alexander Korotkov
wrote:
One quick comment:
It would be good to avoid the extra comparisons of the distances, when
the index doesn't return any lossy items. As the patch stands, it adds one
extra copyDistanc
On Wed, May 13, 2015 at 10:17 PM, Alexander Korotkov
wrote:
> One quick comment:
>>
>> It would be good to avoid the extra comparisons of the distances, when
>> the index doesn't return any lossy items. As the patch stands, it adds one
>> extra copyDistances() call and a cmp_distances() call for
On Wed, May 13, 2015 at 10:16 PM, Heikki Linnakangas
wrote:
> On 04/17/2015 12:05 PM, Alexander Korotkov wrote:
>
>> On Wed, Feb 25, 2015 at 12:15 PM, Alexander Korotkov <
>> aekorot...@gmail.com>
>> wrote:
>>
>> Hi!
>>>
>>> On Tue, Feb 24, 2015 at 5:39 PM, Tomas Vondra <
>>> tomas.von...@2ndqua
On 04/17/2015 12:05 PM, Alexander Korotkov wrote:
On Wed, Feb 25, 2015 at 12:15 PM, Alexander Korotkov
wrote:
Hi!
On Tue, Feb 24, 2015 at 5:39 PM, Tomas Vondra <
tomas.von...@2ndquadrant.com> wrote:
On 17.2.2015 14:21, Alexander Korotkov wrote:
On Sun, Feb 15, 2015 at 2:08 PM, Alexander Ko
On Wed, Feb 25, 2015 at 12:15 PM, Alexander Korotkov
wrote:
> Hi!
>
> On Tue, Feb 24, 2015 at 5:39 PM, Tomas Vondra <
> tomas.von...@2ndquadrant.com> wrote:
>
>> On 17.2.2015 14:21, Alexander Korotkov wrote:
>> > On Sun, Feb 15, 2015 at 2:08 PM, Alexander Korotkov
>> > mailto:aekorot...@gmail.com
Hi!
On Tue, Feb 24, 2015 at 5:39 PM, Tomas Vondra
wrote:
> On 17.2.2015 14:21, Alexander Korotkov wrote:
> > On Sun, Feb 15, 2015 at 2:08 PM, Alexander Korotkov
> > mailto:aekorot...@gmail.com>> wrote:
> >
> > Revised patch with reordering in GiST is attached
> > (knn-gist-recheck-in-gist.patch)
Hi,
On 17.2.2015 14:21, Alexander Korotkov wrote:
> On Sun, Feb 15, 2015 at 2:08 PM, Alexander Korotkov
> mailto:aekorot...@gmail.com>> wrote:
>
> Revised patch with reordering in GiST is attached
> (knn-gist-recheck-in-gist.patch) as well as testing script (test.py).
I meant to do a bit of test
On Sun, Feb 15, 2015 at 2:08 PM, Alexander Korotkov
wrote:
> Following changes has been made in attached patch:
>
> * Get sort operators from pathkeys.
> * Recheck argument of distance function has been reverted.
>
Few comments were added and pairing heap comparison function was fixed in
attac
On Thu, Jan 8, 2015 at 1:12 AM, Alexander Korotkov
wrote:
> On Tue, Dec 16, 2014 at 4:37 PM, Heikki Linnakangas <
> hlinnakan...@vmware.com> wrote:
>
>> Patch attached. It should be applied on top of my pairing heap patch at
>> http://www.postgresql.org/message-id/548ffa2c.7060...@vmware.com. Som
On Tue, Dec 16, 2014 at 4:37 PM, Heikki Linnakangas wrote:
> Patch attached. It should be applied on top of my pairing heap patch at
> http://www.postgresql.org/message-id/548ffa2c.7060...@vmware.com. Some
> caveats:
>
> * The signature of the distance function is unchanged, it doesn't get a
> re
On 10/06/2014 12:36 PM, Emre Hasegeli wrote:
Thanks. The main question now is design of this patch. Currently, it does
all the work inside access method. We already have some discussion of pro
and cons of this method. I would like to clarify alternatives now. I can
see following way:
1. Impl
On 08/03/2014 04:48 PM, Emre Hasegeli wrote:
1. This patch introduces a new "polygon <-> point" operator. That seems
useful on its own, with or without this patch.
Yeah, but exact-knn cant come with no one implementation. But it would
better come in a separate patch.
I tried to split them. S
On Tue, Jan 28, 2014 at 10:54 PM, Heikki Linnakangas
wrote:
> 1. This patch introduces a new "polygon <-> point" operator. That seems
> useful on its own, with or without this patch.
This patch is tracked with this entry in the commit fest app and is
marked as "Ready for committer". Hence I am mov
On Sat, Nov 22, 2014 at 2:20 AM, Peter Geoghegan wrote:
> On Mon, Jan 13, 2014 at 9:17 AM, Alexander Korotkov
> wrote:
> > This patch was split from thread:
> >
> http://www.postgresql.org/message-id/CAPpHfdscOX5an71nHd8WSUH6GNOCf=V7wgDaTXdDd9=gon-...@mail.gmail.com
> >
> > I've split it to sepa
On Mon, Jan 13, 2014 at 9:17 AM, Alexander Korotkov
wrote:
> This patch was split from thread:
> http://www.postgresql.org/message-id/CAPpHfdscOX5an71nHd8WSUH6GNOCf=V7wgDaTXdDd9=gon-...@mail.gmail.com
>
> I've split it to separate thead, because it's related to partial sort only
> conceptually not
> Thanks. The main question now is design of this patch. Currently, it does
> all the work inside access method. We already have some discussion of pro
> and cons of this method. I would like to clarify alternatives now. I can
> see following way:
>
>1. Implement new executor node which perfor
On Mon, Sep 29, 2014 at 6:16 AM, Bruce Momjian wrote:
> On Fri, Sep 26, 2014 at 10:49:42AM +0400, Alexander Korotkov wrote:
> > Does this also fix the identical PostGIS problem or is there
> something
> > PostGIS needs to do?
> >
> >
> > This patch provides general infrastructure for rech
On Fri, Sep 26, 2014 at 10:49:42AM +0400, Alexander Korotkov wrote:
> Does this also fix the identical PostGIS problem or is there something
> PostGIS needs to do?
>
>
> This patch provides general infrastructure for recheck in KNN-GiST. PostGIS
> need corresponding change in its GiST opc
On Fri, Sep 26, 2014 at 5:18 AM, Bruce Momjian wrote:
> On Sun, Sep 14, 2014 at 11:34:26PM +0400, Alexander Korotkov wrote:
> > > Cost estimation of GiST is a big problem anyway. It doesn't care
> (and
> > > can't) about amount of recheck for regular operators. In this
> patch, same
> >
On Sun, Sep 14, 2014 at 11:34:26PM +0400, Alexander Korotkov wrote:
> > Cost estimation of GiST is a big problem anyway. It doesn't care (and
> > can't) about amount of recheck for regular operators. In this patch,
> same
> > would be for knn recheck. The problem is that touching heap
On Thu, Sep 25, 2014 at 9:00 PM, Emre Hasegeli wrote:
> > Fixed, thanks.
>
> Here are my questions and comments about the code.
>
> doc/src/sgml/gist.sgml:812:
> >be rechecked from heap tuple before tuple is returned. If
> >recheck flag isn't set then it's true by default for
> >
> Fixed, thanks.
Here are my questions and comments about the code.
doc/src/sgml/gist.sgml:812:
>be rechecked from heap tuple before tuple is returned. If
>recheck flag isn't set then it's true by default for
>compatibility reasons. The recheck flag can be used only
Rec
On Wed, Sep 17, 2014 at 12:30 PM, Emre Hasegeli wrote:
> > I managed to break it again by ordering rows only by the second column
> > of the index. Test script attached.
>
> I was confused. It is undefined behavior. Sorry for the noise.
>
No problem. Thanks a lot for testing.
--
With bes
> I managed to break it again by ordering rows only by the second column
> of the index. Test script attached.
I was confused. It is undefined behavior. Sorry for the noise.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
> > While looking it at I found a bug. It returns the second column
> > in wrong order when both of the distance functions return recheck = true.
> > Test script attached to run on the regression database. I tried to
> > fix but could not. searchTreeItemDistanceRecheck function is not
> > very e
On Sun, Sep 14, 2014 at 10:09 PM, Emre Hasegeli wrote:
> I added the point to polygon distance operator patch to the open
> CommitFest as ready for committer and added myself as reviewer to
> both of the patches.
>
Thanks.
> Cost estimation of GiST is a big problem anyway. It doesn't care (and
I added the point to polygon distance operator patch to the open
CommitFest as ready for committer and added myself as reviewer to
both of the patches.
> I think that for most use cases just some operators require further sorting
> and some of them not. But it could appear one day that some index
On Sun, Aug 3, 2014 at 5:48 PM, Emre Hasegeli wrote:
> > > 1. This patch introduces a new "polygon <-> point" operator. That seems
> > > useful on its own, with or without this patch.
> >
> > Yeah, but exact-knn cant come with no one implementation. But it would
> > better come in a separate patc
> > 1. This patch introduces a new "polygon <-> point" operator. That seems
> > useful on its own, with or without this patch.
>
> Yeah, but exact-knn cant come with no one implementation. But it would
> better come in a separate patch.
I tried to split them. Separated patches are attached. I c
On Tue, Jan 28, 2014 at 9:32 PM, Heikki Linnakangas wrote:
> On 01/28/2014 04:12 PM, Alexander Korotkov wrote:
>
>> On Tue, Jan 28, 2014 at 5:54 PM, Heikki Linnakangas <
>> hlinnakan...@vmware.com
>>
>>> wrote:
>>>
>>
>> 4. (as you mentioned in the other thread: ) It's a modularity violation
>>>
On 01/28/2014 04:12 PM, Alexander Korotkov wrote:
On Tue, Jan 28, 2014 at 5:54 PM, Heikki Linnakangas
wrote:
4. (as you mentioned in the other thread: ) It's a modularity violation
that you peek into the heap tuple from gist. I think the proper way to do
this would be to extend the IndexScan
On Tue, Jan 28, 2014 at 5:54 PM, Heikki Linnakangas wrote:
> On 01/13/2014 07:17 PM, Alexander Korotkov wrote:
>
>> Here goes a desription of this patch same as in original thread.
>>
>> KNN-GiST provides ability to get ordered results from index, but this
>> order
>> is based only on index infor
On 01/13/2014 07:17 PM, Alexander Korotkov wrote:
Here goes a desription of this patch same as in original thread.
KNN-GiST provides ability to get ordered results from index, but this order
is based only on index information. For instance, GiST index contains
bounding rectangles for polygons, a
Hackers!
This patch was split from thread:
http://www.postgresql.org/message-id/CAPpHfdscOX5an71nHd8WSUH6GNOCf=V7wgDaTXdDd9=gon-...@mail.gmail.com
I've split it to separate thead, because it's related to partial sort only
conceptually not technically. Also I renamed it to "knn-gist-recheck" from
42 matches
Mail list logo
