I may be wrong but we in astronomy have several sky indexing schemes, which
allows to effectively use classical btree index. See
http://www.sai.msu.su/~megera/oddmuse/index.cgi/SkyPixelization
for details. Sergei Koposov has developed Q3C contrib module for
PostgreSQL 8.1+ and we use it with
Try contrib/btree_gist.
I've tried that one, but for my case it didn't help much.
The performance was almost equal or even slower than built-in btree.
On Fri, 17 Mar 2006 08:53:44 -0700
Dan Harris [EMAIL PROTECTED] wrote:
Dan Harris wrote:
Markus Bertheau wrote:
Have you tried using a GIST
On Fri, 17 Mar 2006, Evgeny Gridasov wrote:
Try contrib/btree_gist.
contrib/btree_gist does nothing more than built-in btree - it's just
an support for multicolumn GiST indices.
I've tried that one, but for my case it didn't help much.
The performance was almost equal or even slower than
Markus Bertheau wrote:
Have you tried using a GIST index on lat long? These things are
meant for two-dimensional data, whereas btree doesn't handle
two-dimensional data that well. How many rows satisfy either of the
long / lat condition?
According to the analyze, less than 500 rows
Dan Harris wrote:
Markus Bertheau wrote:
Have you tried using a GIST index on lat long? These things are
meant for two-dimensional data, whereas btree doesn't handle
two-dimensional data that well. How many rows satisfy either of the
long / lat condition?
According to the analyze, less
On 3/16/06, Dan Harris [EMAIL PROTECTED] wrote:
explain analyze
select distinct eventmain.incidentid, eventmain.entrydate,
eventgeo.long, eventgeo.lat, eventgeo.geox, eventgeo.geoy
from eventmain, eventgeo
where
eventmain.incidentid = eventgeo.incidentid and
( long
On Fri, Mar 17, 2006 at 08:34:26 -0700,
Dan Harris [EMAIL PROTECTED] wrote:
Markus Bertheau wrote:
Have you tried using a GIST index on lat long? These things are
meant for two-dimensional data, whereas btree doesn't handle
two-dimensional data that well. How many rows satisfy either of the
On 3/17/06, Bruno Wolff III [EMAIL PROTECTED] wrote:
Have you looked at using the Earth Distance contrib module? If a spherical
model of the earth is suitable for your application, then it may work for you
and might be easier than trying to create Gist indexes yourself.
earth distance = great
Merlin Moncure wrote:
As others will probably mention, effective queries on lot/long which
is a spatial problem will require r-tree or gist. I don't have a lot
of experience with exotic indexes but this may be the way to go.
One easy optimization to consider making is to make an index on
On 3/17/06, Dan Harris [EMAIL PROTECTED] wrote:
Merlin Moncure wrote:
Thanks to everyone for your suggestions. One problem I ran into is that
apparently my version doesn't support the GIST index that was
mentioned. function 'box' doesn't exist ).. So I'm guessing that both
this as well as
Dan Harris [EMAIL PROTECTED] writes:
Furthermore, by doing so, I am tying my queries directly to
postgres-isms. One of the long term goals of this project is to be
able to fairly transparently support any ANSI SQL-compliant back end
with the same code base.
Unfortunately, there isn't any
On Fri, Mar 17, 2006 at 11:41:11PM -0500, Tom Lane wrote:
Dan Harris [EMAIL PROTECTED] writes:
Furthermore, by doing so, I am tying my queries directly to
postgres-isms. One of the long term goals of this project is to be
able to fairly transparently support any ANSI SQL-compliant back
explain analyze
select distinct eventmain.incidentid, eventmain.entrydate,
eventgeo.long, eventgeo.lat, eventgeo.geox, eventgeo.geoy
from eventmain, eventgeo
where
eventmain.incidentid = eventgeo.incidentid and
( long -104.998027962962 and long -104.985957781349 ) and
( lat
13 matches
Mail list logo
