Re: [PERFORM] Nested Loop trouble : Execution time increases more

2005-09-22 Thread Antoine Bajolet
ng more keywords. Thanks to Tom Lane and Simon Riggs. Best regards, Antoine Bajolet Antoine Bajolet a écrit : Hello, Tom Lane a écrit : Antoine Bajolet <[EMAIL PROTECTED]> writes: We are using postgresql in a search engine on an intranet handling throusand of documents. But we a

Re: [PERFORM] Nested Loop trouble : Execution time increases more

2005-09-22 Thread Antoine Bajolet
Hello, Tom Lane a écrit : Antoine Bajolet <[EMAIL PROTECTED]> writes: We are using postgresql in a search engine on an intranet handling throusand of documents. But we ave a big problem when users use more than two search key. I think you need to increase the statistics targe

[PERFORM] Nested Loop trouble : Execution time increases more 1000 time (long)

2005-09-17 Thread Antoine Bajolet
-> Index Scan using fiches_pkey on fiches f (cost=0.00..3.36 rows=1 width=4) (actual time=0.041..0.043 rows=1 loops=2929) Index Cond: (f.f_id = "outer".f_id) Total runtime: 673048.405 ms -- More than 10 minutes ! Is there a specific reason the planner chooses this way ? Can whe do something on the postgresql configuration to avoid this ? Can whe force the planner to use a hash join as it does for the first joins ? Regards, Antoine Bajolet ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster