David Rowley <dgrowleyml@xxxxxxxxx> 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
