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?  (Doug Fields <dfields-pg-general@pexicom.com>)
Список 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 по дате отправления:

Предыдущее
От: Tim Hart
Дата:
Сообщение: Fwd: Ordering of data on calls to user defined aggregate.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Ordering of data on calls to user defined aggregate.