On Thu, Oct 23, 2008 at 12:25 AM, Tom Lane
<tgl@sss.pgh.pa.us> wrote:
> so here are the plans, that's the real table run.
Hmm, well this rowcount estimate is way off:
> -> Hash Anti Join (cost=376.60..37791.22 rows=1
> width=8) (actual time=15.195..8216.448 rows=20000 loops=1)
The fact that it's getting a faster plan despite being completely wrong
about the rowcount means that the cost parameters are way off for your
situation. It looks like you are testing a case where the tables all
fit in memory. Do you expect that to be the reality for your production
use? If so, you might want to reduce random_page_cost to something
close to 1 to reflect it. If not, it'd be a good idea to test with more
realistically-sized tables before deciding what's "faster".
tell me about it. even tho I am a rookie here, that cough my attention too.
I'm not sure why the rowcount estimate is so far off, but the antijoin
code is all new and probably there's an estimation bug in there
somewhere. (You didn't get this plan, or anything at all like it,
from 8.1 ;-))
nope, that's up2date cvs head. I always test stuff on cvs head first, only run 8.1 in the office/production/testing - and I already suggested to the powers to be, that we need to move to 8.3 pronto, for several million reasons.
Thanks Tom for your opinion :)
--
GJ
