Jeff,
I checked the archive and it works with 7.1 release
we've implemented only several functions for box, so you may use
them as example for remaining types.
Regards,
Oleg
On Wed, 18 Apr 2001, Oleg Bartunov wrote:
> On Tue, 17 Apr 2001, Jeff Hoffmann wrote:
>
> > Oleg
On Tue, 17 Apr 2001, Jeff Hoffmann wrote:
> Oleg Bartunov wrote:
> >
> > GiST is great !
> >
> > You may look at http://www.sai.msu.su/~megera/postgres/gist/
> > for GiST implementation of RTree - it could be not compiled with 7.1
> > release due to some api changes, but it's not difficult to do.
Oleg Bartunov wrote:
>
> GiST is great !
>
> You may look at http://www.sai.msu.su/~megera/postgres/gist/
> for GiST implementation of RTree - it could be not compiled with 7.1
> release due to some api changes, but it's not difficult to do.
it looks like i just wasted a good couple of hours tr
GiST is great !
You may look at http://www.sai.msu.su/~megera/postgres/gist/
for GiST implementation of RTree - it could be not compiled with 7.1
release due to some api changes, but it's not difficult to do.
If somebody want it I could contribute it to contrib area.
Tom,
what we need to do to i
Jeff Hoffmann <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> How the heck did the GIST index code get developed/tested without some
>> opclasses?
> doing some digging at berkeley, i found the original pggist patch file
> that created the gist access method & gist_box_ops opclass (among
> others
Jeff Hoffmann <[EMAIL PROTECTED]> writes:
> I know there are a couple of GiST examples in contrib (seg, cube &
> intarray), but i thought there used to be at least a gist_box_ops.
I don't recall any such thing having been removed, but it does seem
peculiar that there are no GIST opclasses in the
Tom Lane wrote:
>
> I don't recall any such thing having been removed, but it does seem
> peculiar that there are no GIST opclasses in the standard distribution.
> How the heck did the GIST index code get developed/tested without some
> opclasses?
doing some digging at berkeley, i found the orig
Tom Lane wrote:
> BTW, you should also look at the GIST stuff and figure out whether
> it might not be better to develop a GIST opclass instead of rtree.
> In the long run I suspect GIST will be better supported than rtree,
> since it's more general.
>
> regards, tom lane
Julian Scarfe wrote:
> >
> > explain select * from nodes where box(node,node) @ '((1,1),(3,3))'::box;
> > NOTICE: QUERY PLAN:
> > Seq Scan on nodes (cost=0.00..1.10 rows=1 width=28)
From: "Jeff Hoffmann" <[EMAIL PROTECTED]>
> this should work, assuming you have enough points to make a differen
Jeff Hoffmann <[EMAIL PROTECTED]> writes:
> yes, it does seem like a little more work, but there doesn't seem to be
> a lot of usage of the geometric functions by the developers to look at
> missing features -- they're mostly just reactive to problems.
Jeff's correct, none of the core developers
Julian Scarfe wrote:
>
> It hadn't occured to me that the index would simply not be used and I'm
> grateful for the pointer to the appropriate variable.
i wouldn't recommend turning off sequential scans for day-to-day usage,
but it certainly can be useful for debugging and testing. if you have
Julian Scarfe wrote:
>
> explain select * from nodes where box(node,node) @ '((1,1),(3,3))'::box;
> NOTICE: QUERY PLAN:
> Seq Scan on nodes (cost=0.00..1.10 rows=1 width=28)
>
this should work, assuming you have enough points to make a difference
(in the optimizer's mind, at least). the opti
Am I missing the point (no pun intended ;-) of RTREE indices?
I was expecting a "point_ops" opclass or similar...
[7.1 on RedHat 6.2]
SELECT am.amname AS acc_name,
opc.opcname AS ops_name,
COUNT(*)
FROM pg_am am, pg_amop amop,
pg_opclass opc
WHERE amop.amopid
13 matches
Mail list logo
