2010/1/12 Teodor Sigaev teo...@sigaev.ru:
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
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 pram...@cleverelephant.ca 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:
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 gsst...@mit.edu wrote:
On Wed,
On Mon, Jan 4, 2010 at 5:33 PM, Paul Ramsey pram...@cleverelephant.ca 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 :)
On Wed, Dec 30, 2009 at 4:56 PM, Robert Haas robertmh...@gmail.com 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
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
On Wed, Dec 30, 2009 at 9:20 AM, Oleg Bartunov o...@sai.msu.su 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
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
2009/12/30 Teodor Sigaev teo...@sigaev.ru:
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
On Wed, Dec 30, 2009 at 12:16 PM, Robert Haas robertmh...@gmail.com wrote:
2009/12/30 Teodor Sigaev teo...@sigaev.ru:
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
2009/11/26 Teodor Sigaev teo...@sigaev.ru:
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
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
Teodor Sigaev teo...@sigaev.ru 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
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
Teodor Sigaev teo...@sigaev.ru 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
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
17 matches
Mail list logo
