Guillaume Lelarge <guillaume@lelarge.info> 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
