Re: Force a merge join?
От | Tom Lane |
---|---|
Тема | Re: Force a merge join? |
Дата | |
Msg-id | 23478.1021753149@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Force a merge join? (Doug Fields <dfields-pg-general@pexicom.com>) |
Ответы |
Re: Force a merge join?
|
Список | pgsql-general |
Doug Fields <dfields-pg-general@pexicom.com> writes: > In fact, yes it does. How do I know? Very simple: I did a SELECT * INTO ... > to copy my real table to a testing table so I could refactor it. Then I did > the usual EXPLAIN ANALYZE queries, and it was using merge joins. Then, I > did an "ANALYZE" (which is like VACUUM ANALYZE without the slow VACUUM) and > voila - nested loops and half second queries turning into five minute > nightmares. Then enable_nestloop would fix the problem again after that. Could we see the usual details here? Before and after EXPLAIN ANALYZE, and the schemas and pg_stats rows for the tables involved. BTW, you don't really have to reload a table to get back to the "unanalyzed" condition for testing purposes. You can just manually delete the rows from pg_statistic: delete from pg_statistic where starelid = (select oid from pg_class where relname = 'mytable'); regards, tom lane
В списке pgsql-general по дате отправления: