I think I understand now after reading the notes here on the merge join algorithm:
https://github.com/postgres/postgres/blob/4ea51cdfe85ceef8afabceb03c446574daa0ac23/src/backend/executor/nodeMergejoin.c The index scanning node doesn't know the max id of the vehicle table and so can't know when to stop looking for the next tuple that matches the join. Doesn't seem like any easy way to improve that case. I imagine it is a fairly common pattern though. Any time metadata about entities modeled in different tables, is stored in the same table, and the distribution of the number of each entity type is skewed, this situation will arise. Best, Jake -- View this message in context: http://postgresql.nabble.com/Merge-Join-chooses-very-slow-index-scan-tp5842523p5842633.html Sent from the PostgreSQL - performance mailing list archive at Nabble.com. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
