Re: Force a merge join?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Doug Fields <dfields-pg-general(at)pexicom(dot)com>
Cc: "Ian Harding" <ianh(at)tpchd(dot)org>, pgsql-general(at)postgresql(dot)org
Subject: Re: Force a merge join?
Date: 2002-05-18 20:19:09
Message-ID: 23478.1021753149@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Doug Fields <dfields-pg-general(at)pexicom(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Joel Burton 2002-05-18 21:13:04 Re: Ordering of data on calls to user defined aggregate.
Previous Message Tim Hart 2002-05-18 20:00:26 Fwd: Ordering of data on calls to user defined aggregate.