On Oct 4, 2006, at 4:40 PM, Ben wrote:
I'm surprised (though probably just because I'm ignorant) that it would have so much sequential scanning in there. For instance, because n is going to have at most a couple dozen rows, it seems that instead of scanning all of public.track, it should be able to convert my "t.length between a and b" clause to some between statements or'd together. Or at least, it would be nice if the planner could do that.
That would require the planner having that knowledge at plan-time, which it can't without actually querying the database. One thing that might work wonders is performing the n query ahead of time and then sticking it in an array... that might speed things up.
Worst case, you could run the n query, and then run the rest of the query for each row of n you get back.
Better yet... send us a patch that allows the planner to look into what a subselect will return to us. ;)
-- Jim Nasby jim@xxxxxxxxx EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) -- Jim Nasby jimn@xxxxxxxxxxxxxxxx EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
