Re: any hope for my big query?

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)