Re: any hope for my big query? - Mailing list pgsql-performance

From Jim Nasby
Subject Re: any hope for my big query?
Date
Msg-id AB73891F-7475-4ADE-9D90-04E7CC1545EF@enterprisedb.com
Whole thread Raw
In response to Re: any hope for my big query?  (Ben <bench@silentmedia.com>)
List pgsql-performance
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)



pgsql-performance by date:

Previous
From: "Carlo Stonebanks"
Date:
Subject: Re: Performance Optimization for Dummies 2 - the SQL
Next
From: Jim Nasby
Date:
Subject: Re: Unsubscribe