David Rowley <dgrowleyml@gmail.com> writes:
> I'm not sure if you're asking for help here because you need planning
> to be faster than it currently is, or if it's because you believe that
> planning should always be faster than execution. If you think the
> latter, then you're mistaken.
Yeah. I don't see anything particularly troubling here. Taking
circa three-quarters of a millisecond (on typical current hardware)
to plan a four-way join on large tables is not unreasonable.
In most cases one could expect the execution of such a query to
take a good bit longer than that. I think the OP is putting too
much emphasis on an edge case where execution finishes quickly
because there are in fact zero rows matching the uuid restriction.
BTW, in addition to the duplicative indexes, I wonder why the
uuid columns being joined on aren't all of "uuid" type. While
I doubt fixing that would move the needle greatly, it still
seems sloppy.
regards, tom lane