=?ISO-8859-1?Q?Andr=E9_Volpato?= <andre.volpato@ecomtecnologia.com.br> writes: > Besides the (expected) weak guess on rows for both servers on seq scan > on jtest, there is something nasty with [2] that prevents the planner to > use the index. There isn't anything "preventing" either version from choosing any of the three plans, as you can easily prove for yourself by experimenting with enable_nestloop/enable_mergejoin/enable_hashjoin. The cost estimates seem close enough that random variations in ANALYZE stats would change which one looks cheapest. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster

Gregory Stark <stark@enterprisedb.com> writes: > But I'm curious if you turn off mergejoin whether you can get a Nested Loop > plan and what cost 8.3 gives it. It looks to me like 8.3 came up with a higher > cost for Nested Loop than 8.1.9 (I think 8.1.10 came out with some planner > fixes btw) and so it's deciding these other plans are better. And they might > have been better for the imaginary scenario that the planner thinks is going > on. Actually, now that I think about it, 8.3 should be *more* likely than 8.1 to choose a nestloop-with-inner-indexscan plan. 8.1 didn't have the changes to allow a discount for repeated inner indexscans. I'm wondering if (a) the 8.1 installation being compared to had some planner cost parameter changes that were not copied into the 8.3 installation; or (b) the only reason 8.1 likes the nestloop plan is that it has no statistics on the test tables, whereas 8.3 does have stats because of autovacuum being on by default. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly