Hi Yuri and Radu-Stefan
I would'nt give too fast on PostgreSQL!
When looking at your query plan I wonder if one could reformulate the query
to compute the ST_DWithin first (assuming you have an index on the node
geometries!) before it filters the tags.
To investigate that you could formulate a
Hi
Sorry, referring to GIST index in my mail before was no good idea.
The bottom line still is, that the query (as recommended by the docs)
and the planner don't choose the index which makes it slow - unless
the original query...
select id,title,left(content,100)
from fulltextsearch
where
I tried sending this a couple days ago but I wasn't a member of the group
so I think it's in limbo. Apologies if a 2nd copy shows up at some point.
We recently migrated a 1.3TB database from 8.4 to 9.2.2 on a new server. As
part of this migration we added partitions to the largest tables so we
Hello
2013/7/19 Skarsol skar...@gmail.com:
I tried sending this a couple days ago but I wasn't a member of the group so
I think it's in limbo. Apologies if a 2nd copy shows up at some point.
We recently migrated a 1.3TB database from 8.4 to 9.2.2 on a new server. As
part of this migration
SELECT * FROM FullTextSearch WHERE content_tsv_gin @@
plainto_tsquery('english', 'good');
It's slow ( 30 sec.) for some GB (27886 html files, originally 73 MB zipped).
The planner obviously always chooses table scan
Hello,
A probable reason for the time difference is the cost for
Hi Marc
Thanks a lot for your hint!
You mean doing a SET track_counts (true); for the whole session?
That would be ok if it would be possible just for the gin index.
It's obviously an issue of the planner estimation costs.
The data I'm speaking about (movies) has a text attribute which has
a
