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.


---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Reply via email to