2010/1/12 Teodor Sigaev :
> Changes:
>
> - split patch to several ones
> - sync with current CVS
>
> Patch set is based on 0.5.1 version, difference between 0.5 and 0.6 should
> be only in planner patch.
>
> builtin_knngist_itself-0.6.gz - patch to the gist itself
> builtin_knngist_proc-0.6.gz - p
Changes:
- split patch to several ones
- sync with current CVS
Patch set is based on 0.5.1 version, difference between 0.5 and 0.6 should be
only in planner patch.
builtin_knngist_itself-0.6.gz - patch to the gist itself
builtin_knngist_proc-0.6.gz - patch for support knnsearch in point_ops
Robert,
On Mon, 4 Jan 2010, Robert Haas wrote:
On Mon, Jan 4, 2010 at 5:33 PM, Paul Ramsey wrote:
I'm sure whatever conclusion -hackers comes to in the end will be the
best for pgsql, and I'll be supportive. But until then, let me note
from the PostGIS point-of-view: sure would be great to ge
On Mon, Jan 4, 2010 at 5:33 PM, Paul Ramsey wrote:
> I'm sure whatever conclusion -hackers comes to in the end will be the
> best for pgsql, and I'll be supportive. But until then, let me note
> from the PostGIS point-of-view: sure would be great to get this in for
> 8.5 :)
That's good to know.
I'm sure whatever conclusion -hackers comes to in the end will be the
best for pgsql, and I'll be supportive. But until then, let me note
from the PostGIS point-of-view: sure would be great to get this in for
8.5 :)
P.
On Thu, Dec 31, 2009 at 4:26 AM, Greg Stark wrote:
> On Wed, Dec 30, 2009 at
On Wed, Dec 30, 2009 at 4:56 PM, Robert Haas wrote:
>
> From my point of view, what makes a patch invasive is the likelihood
> that it might break something other than itself. For example, your
> patch touches the core planner code and the core GIST code, so it
> seems possible that adding suppor
On Wed, Dec 30, 2009 at 12:16 PM, Robert Haas wrote:
> 2009/12/30 Teodor Sigaev :
>>> changes should be made. It does also need to be updated to CVS HEAD,
>>> as it no longer applies cleanly.
>>
>> The reason was a point_ops patch, some OIDs become duplicated. Both attached
>> patches are synced
2009/12/30 Teodor Sigaev :
>> changes should be made. It does also need to be updated to CVS HEAD,
>> as it no longer applies cleanly.
>
> The reason was a point_ops patch, some OIDs become duplicated. Both attached
> patches are synced with current CVS.
Thanks! I will take a look.
>> I tend to
Teodor Sigaev escribió:
> Actually, it's easy to split patch to several ones:
> - contrib/pg_trgm
> - contrib/btree_gist
> - knngist itself
> - planner changes
+1 on the split patches. I wonder about the opr_sanity test change ...
why is it necessary?
--
Alvaro Herrera
On Wed, Dec 30, 2009 at 9:20 AM, Oleg Bartunov wrote:
> From metodological point of view I don't quite understand how to measure
> the value of development, I mean what'is a "big patch", "invasive patch".
I want to speak specifically to this question because I think it's a
good one. Of course, I
Robert,
On Wed, 30 Dec 2009, Robert Haas wrote:
Based on the feedback provided on this patch so far, it looks like
some changes are probably needed, but it's not entirely clear whether
the feedback provided is sufficient to provide guidance on what
changes should be made. It does also need to
2009/11/26 Teodor Sigaev :
> Hi!
>
> Contrib module is reworked as a patch for current GiST. Now GiST supports
> KNN-search, the query looks like
> SELECT * FROM point_tbl ORDER BY f1 <-> '0,1';
> or
> SELECT * FROM point_tbl WHERE f1 <@ '(-10,-10),(10,10)':: box ORDER BY f1
> <-> '0,1';
> Plans ar
Teodor Sigaev writes:
> Do you suggest to construct that clauses from pathkey representation? And
> append
> constructed clauses to indexquals in create_indexscan_plan?
I'd probably have to read the patch to make any intelligent suggestions
... and right now I'm busy with patches that are alr
Done, IndexScan and IndexPath have separate field to store order clauses.
Why? Isn't that redundant with the pathkey structures? We generate
enough paths during a complex planning problem that I'm not in favor
of adding unnecessary structures to them.
I found two ways to add support of knn-se
Teodor Sigaev writes:
>> Planner (find_usable_indexes function, actually) could push pathkey
>> expression into restriction clauses of index. I'm not fully satisfied
>> with this piece of code, but, may be, someone has a better idea. I
>> though about adding separate indexorderquals in IndexPat
Planner (find_usable_indexes function, actually) could push pathkey
expression into restriction clauses of index. I'm not fully satisfied
with this piece of code, but, may be, someone has a better idea. I
though about adding separate indexorderquals in IndexPath structure...
Done, IndexScan an
BTW, it's possible to add this feature to plain btree by changing
traversal algorithm, but I'm fill enough power to do it.
Sorry, I'm NOT fill enough power to do it.
%-), I'm NOT FEEL enough power to do it.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
BTW, it's possible to add this feature to plain btree by changing
traversal algorithm, but I'm fill enough power to do it.
Sorry, I'm NOT fill enough power to do it.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW
explain select col1 from s order by abs(col1 - 5) limit 10;
is the one-dimensional equivalent of the type of query you're proposing
Exactly, it's already done in next version of patch :)
and that doesn't work either until you put an index on abs(col1 - 5),
then it just works, but only for k
Hi!
Contrib module is reworked as a patch for current GiST. Now GiST supports
KNN-search, the query looks like
SELECT * FROM point_tbl ORDER BY f1 <-> '0,1';
or
SELECT * FROM point_tbl WHERE f1 <@ '(-10,-10),(10,10)':: box ORDER BY f1 <->
'0,1';
Plans are:
EXPLAIN (COSTS OFF)
SELECT * FROM poi
On Mon, 2009-11-23 at 20:44 +0300, Teodor Sigaev wrote:
> Old way:
> SELECT coordinates, (coordinates <-> '5.0,5.0'::point) AS dist FROM
> spots
> order by dist asc LIMIT 10;
>
> Time: 1024.242 ms
>
> knn-search:
> SELECT coordinates, (coordinates <-> '5.0,5.0'::point) AS dist FROM
> spots
> WHER
Teodor Sigaev wrote:
>>> 1. KNNGiST is about 5% slower than GiST on non-knn search queries, like
>>> contains or contained by, because of some overhead of new algorithm of
>>> tree traversal
>>
>> Is it possible to use the regular GiST traversal algorithm on a
>> KNNGiST-tree, when performing r
I think you'll need to work on that. A WHERE qual shouldn't imply a sort
order. You'll have to teach the planner how to use the index to speed up
a query in the first form.
Of course, right now it is a working prototype.
1. KNNGiST is about 5% slower than GiST on non-knn search queries, like
Teodor Sigaev wrote:
> we'd like to present contrib module for CVS HEAD, which contains
> implementation of knn (k nearest neighbourhood) search in PostgreSQL,
> see README.knngist for
> details.
Cool!
> Old way:
> SELECT coordinates, (coordinates <-> '5.0,5.0'::point) AS dist FROM spots
> order
Hi there,
http://www.sigaev.ru/misc/knngist-0.11.tar.gz
we'd like to present contrib module for CVS HEAD, which contains implementation
of knn (k nearest neighbourhood) search in PostgreSQL, see README.knngist for
details. KNNGiST is an extension of existing GiST, which inherits most of
their
25 matches
Mail list logo
