Josh Berkus <josh@xxxxxxxxxxxx> writes: > I guess what I'm really not understanding is why it's calculating a cost > of 3.7m for the index scan, and then discarding that *entire* cost and > not including it in the total cost of the query? It isn't ... or at least, you've offered no evidence that it is. It's discounting some fraction of the cost on the (apparently correct) basis that the merge won't read that input all the way to the end. Whether it's discounted by an appropriate fraction is hard to tell from the information given. The actual rows count is about a quarter the whole-scan estimate, so a multiplier of 0.25 seems right in hindsight, and that seems to match up roughly right with the mergejoin cost estimate --- but not knowing the actual table size, there's a lot of uncertainty here. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
