Re: join question

On Thu, Oct 23, 2008 at 12:25 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?=" <gryzman(at)gmail(dot)com> writes:
> > 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