From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | "Alberto Dalmaso" <dalmaso(at)clesius(dot)it>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: performance with query |
Date: | 2009-06-18 19:39:21 |
Message-ID: | 15037.1245353961@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> With all the optimizer options on, and the from_collapse_limit and
> join_collapse_limit values both set to 100, run an EXPLAIN (no
> ANALYZE) on your big problem query. Let us know how long the EXPLAIN
> runs. If it gets any errors, copy and paste all available
> information. (General descriptions aren't likely to get us very far.)
> Since EXPLAIN without ANALYZE only *plans* the query, but doesn't run
> it, it should not take long to do this.
One issue here is that with the collapse limits cranked up to more than
geqo_threshold, he's going to be coping with GEQO's partially-random
plan selection; so whatever he reports might or might not be especially
reflective of day-to-day results. I'm tempted to ask that he also push
up geqo_threshold. It's possible that that *will* send the planning
time to the moon; but it would certainly be worth trying, to find out
what plan is produced.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Alban | 2009-06-18 19:42:47 | Re: Strange performance response for high load times |
Previous Message | Kevin Grittner | 2009-06-18 19:26:58 | Re: performance with query |