Anyway, the query has no clue that because of the final LIMIT 100 that the two different feeding queries are just going to happen to end up providing the same result. Maybe, in this particular instance, it is theoretically possible to make such a proof but generally that is not the case and so such an optimization has not made into the codebase even if it theoretically could be done (I'm not convinced it could but do not know enough to explain to someone else why I have that impression).
I do not know enough to answer why this situation is any different from a similar partitioning scenario. An example showing exactly what a similar partitioning query looks like would help in this regard.
If you are looking for considerably more insight into the planner workings and why it does or doesn't do something you will need to wait for others. I can, to a reasonable degree, deconstruct a pair of queries and either explain or guess as to why things are happening but that is mostly applied deductive reasoning and not because I have any particular insight into the codebase.
Thanks again for your time. Let's just wait for someone else and see where this will end up going.
