I would like to use the GEO2D function in Sphinx (SphinxQL) but I would like to use it without searching an index.
I have the polygon and the latitude and longitude already and just want to calculate if the point is inside the polygon. So this is what I want:
SELECT CONTAINS(GEOPOLY2D($polygon),$lat_deg, $long_deg)
in MySQL you could run a query without specifying a database:
SELECT 1+1
How could I do this in Sphinx? I already tried to run it with an index (FROM index LIMIT 1) but that seems to do a full table scan and thus take a long time.
I could make a new index with just one record but maybe there is another way?
Related
I have a database of points (10 million) in postgresql 12 which has the postgis extension. I have created a gist index on the points column and I need to filter the points based on distance from a given point. It seems that the index is not used. I run the following explain:
EXPLAIN
SELECT actual_location
FROM geometries
WHERE ST_DWithin(ST_SetSRID(ST_MakePoint(30,30), 4326), actual_location, 100000, true);
which yields:
so it seems it only does a parallel seq scan. Am I getting something wrong here? Should I be using a different index type? When the database was populated with 1 million points, it returned results in about 1.3 seconds. With 10 million it goes to about 11-13 which is not acceptable for a user of my application to wait that much time.
Turns out I should have created the index like so:
CREATE INDEX example_idx ON geometries USING GIST (geography(actual_location));
got the following query
SELECT * FROM myDB.dbo.myTable
WHERE name = 'Stockholm'
or
SELECT * FROM myDB.dbo.myTable
WHERE name LIKE('Stockholm')
I have created a fulltext index which will be taken when I use CONTAINS(name,'Stockholm') but in the two cases above it performs only a clustered index scan. This is way to slow, above 1 second. I'm a little confused because I only want to search for perfect matches which should be as fast as CONTAINS(), shouldn't it? I've read that LIKE should use a index seek at least, if you don't use wildcards respectively not using wildcards at the beginning of the word you're searching for.
Thank you in advance
I bet you have no indexes on the name column. A Full-Text index is NOT a database index and is NOT used, unless you use a full-text predicate like CONTAINS.
As stated by #Panagiotis Kanavos and #Damien_The_Unbeliever there was no "non-fulltext" index on my name column. I had to simply add a index with the following query:
CREATE INDEX my_index_name
ON myDB.dbo.myTable (name)
This improves the performance from slightly above one second to under a half second.
Say I have a document, which looks like
{loc:{start:[x,y],end:[x1,y1]}}
with 2dsphere index, and I want to search for all the documents that have the same start and end points in one query. Is it possible to do it in MongoDB?
A geospatial index can only cover one field with a legacy coordinate pair (array with two values) or a valid GeoJSON Point, Polygon or LineString. That means you can only index either the start-position or the end-position with a geospatial index.
But this is not a problem when you are searching for an exact match. A 2dsphere index offers some additional geographical operators, but when you only need to test for exact equality, you don't need those and can treat your geo-coordinates like plain old data. So when you just add a vanilla index on the loc field and use a vanilla find() with the values you are searching, you will get your matches.
I have a database and want to be able to look up in a table a search that's something like:
select * from table where column like "abc%def%ghi"
or
select * from table where column like "%def%ghi"
Is there a way to index the column so that this isn't too slow?
Edit:
Can I also clarify that the database is read only and won't be updated often.
Options for text search and indexing include:
full-text indexing with dictionary based search, including support for prefix-search, eg to_tsvector(mycol) ## to_tsquery('search:*')
text_pattern_ops indexes to support prefix string matches eg LIKE 'abc%' but not infix searches like %blah%;. A reverse()d index may be used for suffix searching.
pg_tgrm trigram indexes on newer versions as demonstrated in this recent dba.stackexchange.com post.
An external search and indexing tool like Apache Solr.
From the minimal information given above, I'd say that only a trigram index will be able to help you, since you're doing infix searches on a string and not looking for dictionary words. Unfortunately, trigram indexes are huge and rather inefficient; don't expect some kind of magical performance boost, and keep in mind that they take a lot of work for the database engine to build and keep up to date.
If you need just to, for instance, get unique substrings in an entire table, you can create a substring index:
CREATE INDEX i_test_sbstr ON tablename (substring(columname, 5, 3));
-- start at position 5, go for 3 characters
It is important that the substring() parameters in the index definition are
the same as you use in your query.
ref: http://www.postgresql.org/message-id/BANLkTinjUhGMc985QhDHKunHadM0MsGhjg#mail.gmail.com
For the like operator use one of the operator classes varchar_pattern_ops or text_pattern_ops
create index test_index on test_table (col varchar_pattern_ops);
That will only work if the pattern does not start with a % in which case another strategy is required.
We have a table that has millions of rows with PostGIS geometries in them. The query we want to perform is: what are the most recent entries that fall within a bounding geometry? The problem with this query is that we'll often have a large number of items that match the bounding box (which has around 5km in radius), and Postgres will then have to re-check all the returned items inside the bounding box to get their timestamp, then sort and return the latest N.
It feels like what we need is a (compound?) index that takes into account both the GIST spatial index and the timestamp as well. Is such a thing possible? I've tried several combinations in the CREATE INDEX step and nothing's worked so far.
I'd rather make two indexes, one spatial and the second on the timestamp column. PostgreSQL can combine indexes pretty nice and it doesn't need to 're-check' found rows. It could use indexes to get the rows within the geometry and sort them using the other index.