Re: [PERFORM] FTS performance issue - planner problem identified (but only partially resolved)

2013-07-29 Thread Kevin Grittner
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

Re: [PERFORM] FTS performance issue - planner problem identified (but only partially resolved)

2013-07-29 Thread Stefan Keller
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]

Re: [PERFORM] FTS performance issue - planner problem identified (but only partially resolved)

2013-07-20 Thread Marc Mamin
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

Re: [PERFORM] FTS performance issue - planner problem identified (but only partially resolved)

2013-07-19 Thread Marc Mamin
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

Re: [PERFORM] FTS performance issue - planner problem identified (but only partially resolved)

2013-07-19 Thread Stefan Keller
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

[PERFORM] FTS performance issue - planner problem identified (but only partially resolved)

2013-07-18 Thread Stefan Keller
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