Stefan Keller sfkel...@gmail.com wrote:
Finally, setting random_page_cost to 1 helps also - but I don't
like this setting neither.
Well, you should learn to like whichever settings best model your
actual costs given your level of caching and your workload. ;-)
FWIW, I have found page costs
Hi Kevin
Well, you're right :-) But my use cases are un-specific by design
since I'm using FTS as a general purpose function.
So I still propose to enhance the planner too as Tom Lane and your
colleague suggest based on repeated similar complaints [1].
Yours, Stefan
[1]
Von: Stefan Keller [sfkel...@gmail.com]
Gesendet: Samstag, 20. Juli 2013 01:55
Hi Marc
Thanks a lot for your hint!
You mean doing a SET track_counts (true); for the whole session?
No,
I mean
ALTER TABLE table ALTER ts_vector_column SET STATISTICS
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
Hi
At 2013/2/8 I wrote:
I have problems with the performance of FTS in a query like this:
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