| From: | Jeff <threshar(at)torgo(dot)978(dot)org> |
|---|---|
| To: | "Gary Doades" <gpd(at)gpdnet(dot)co(dot)uk> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: planner/optimizer question |
| Date: | 2004-04-30 12:32:16 |
| Message-ID: | 69EF9EF2-9AA2-11D8-A4E1-000D9366F0C4@torgo.978.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Apr 30, 2004, at 3:01 AM, Gary Doades wrote:
[ pg query plan, etc ]
I wonder if other parts of the plan are affecting the speed.
I've recently run into a case where a merge join plan was chosen for
this query, which took 11 seconds to execute. Forcing it to pick a
nested loop join dropped it to 3. (Updating my
default_statistics_target to 500 caused the planner to choose nested
loop join)
So, is the plan really the same?
A better comparision query may be a simple "select a from mytable
where a between foo and bar" to get an index scan. In that case its a
straight up, vanilla index scan. Nothing else getting in the way.
--
Jeff Trout <jeff(at)jefftrout(dot)com>
http://www.jefftrout.com/
http://www.stuarthamm.net/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pailloncy Jean-Gérard | 2004-04-30 12:45:55 | Re: Fwd: FreeBSD, PostgreSQL, semwait and sbwait! |
| Previous Message | Manfred Koizar | 2004-04-30 07:33:13 | Re: analyzer/planner and clustered rows |