Guillaume Lelarge <guillaume@xxxxxxxxxxxx> writes: > * The planner seems to read tables to generate the plans and/or select the > right plan. Why does it do that? I thought it only reads indexes if needed, > but it is quite clear it reads tables also. I'm guessing to some extent, but it seems plausible that this is an artifact of the logic that tries to get the current min and/or max column values to be sure we are estimating mergejoin costs accurately. Normally, yeah, that is only supposed to consult the extremal values in indexes and therefore not take very long. However, we've had to go back to the drawing board several times to fix cases where it made a lot of expensive table accesses because the extremal index entries were of uncertain liveness. That behavior could very easily depend on whether you're in a primary or standby server. Are there any tables in this query where extremal values of the join key are likely to be in recently-added or recently-dead rows? Does VACUUM'ing on the primary help? And, not to put too fine a point on it, but does updating to a recent minor release help? In a quick scan of the git history I don't see any related bugfixes later than 11.5, but I might've missed something. regards, tom lane
