On Mon, May 2, 2011 at 3:58 AM, Claudio Freire klaussfre...@gmail.com wrote:
Hash joins are very inefficient if they require big temporary files.
Hmm, that's not been my experience. What have you seen?
I've seen a 64-batch hash join beat out a
nested-loop-with-inner-indexscan, which I never
Thanks for replies. Finally I have used UNION and JOINS, which helped. Mainly
the UNION helped a lot. Now the query takes 1sec max. Thanks a lot.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Query-improvement-tp4362578p4378163.html
Sent from the PostgreSQL -
Thanks for reply both UNION and JOINS helped. Mainly the UNION helped a lot.
Now the query takes 1sec max. Thanks a lot.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Query-improvement-tp4362578p4378157.html
Sent from the PostgreSQL - performance mailing list archive
Thanks a lot for reply. Finally I have used UNION, but thanks for your help.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Query-improvement-tp4362578p4378160.html
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.
--
Sent via
Here is EXPLAIN ANALYZE:
Limit (cost=136568.00..136568.25 rows=100 width=185) (actual
time=1952.174..1952.215 rows=100 loops=1)
- Sort (cost=136568.00..137152.26 rows=233703 width=185) (actual
time=1952.172..1952.188 rows=100 loops=1)
Sort Key: ((ts_rank(pc.textvector,
On Mon, May 2, 2011 at 10:54 PM, Mark marek.bal...@seznam.cz wrote:
but the result have been worst than before. By the way is there a posibility
to create beeter query with same effect?
I have tried more queries, but this has got best performance yet.
Well, this seems to be the worst part:
On Mon, May 2, 2011 at 10:54 PM, Mark marek.bal...@seznam.cz wrote:
but the result have been worst than before. By the way is there a
posibility
to create beeter query with same effect?
I have tried more queries, but this has got best performance yet.
Well, this seems to be the worst
