On Thu, Oct 23, 2008 at 12:25 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?=" <[EMAIL PROTECTED]> 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
