Christophe Pettus <xof@xxxxxxxxxxxx> writes: > Thanks, that makes sense. Something a colleague of mine just noticed is that the estimate cost of the Index Scan node isn't being included in the cost of the Merge Join above it, which makes the Merge Join seem much cheaper than it really is. Could this be a planner bug? No, that looks sane. It's probably expecting that the range of keys on the right-hand side is a lot less than the range of keys on the left, and thus the merge won't have to read all of the left side. Since the output shows an estimated total number of rows in the LHS of 84 million, but the join stopped after reading 20 million of them, it looks like that effect did in fact occur. If the planner had that fraction dead on, it would only have charged the mergejoin with a quarter of the indexscan's total estimated cost. It's hard to tell though exactly what it did think. The whole thing looks a bit weird to me --- why did it not use a nestloop join with inner indexscan on charlie? With 7000 rows on the other side, the estimated cost for that shouldn't have been more than about 30000 ... 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
