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
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. |