"=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?=" <gryzman@xxxxxxxxx> 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". 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 ;-)) regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
