On Wed, Feb 21, 2018 at 7:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> What is the planner doing when trying to find the current live max value of > the column?
It's trying to estimate whether a mergejoin will be able to stop short of reading all the tuples from the other side of the join. (For instance, if you've got 1,3,5 on one side, and 1,4,5,7,8,9,19 on the other, the second input doesn't have to be read past "7" because once we run off the end of the first input, we know we couldn't see any matches later on the second input. So the planner wants to compare the ending key value on each side to the key distribution on the other side, to see what this might save.) Now, that's a unidirectional question for any particular mergejoin plan, so that for any one cost estimate it's only going to need to look at one end of the key range. But I think it will consider merge joins with both sort directions, so that both ends of the key range will get investigated in this way. I might be wrong though; it's late and I've not looked at that code in awhile ...
I'm thinking the least painful solution here might be to set enable_mergejoin = false for this particular query, since the rows joined are quite sparse.