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.
From:
Sergey Shchukin Date: Subject:
Re: [GENERAL] Re: [pgadmin-support] Issue with a hanging apply process
on the replica db after vacuum works on primary
