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@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
--
Jim Nasby jimn@enterprisedb.com
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
