Maksim Milyutin <milyutinma@xxxxxxxxx> writes: > On hot standby I faced with the similar problem. > ... > is planned 4.940 ms on master and *254.741* ms on standby. Presumably the problem is that the standby isn't authorized to change the btree index's "entry is dead" bits, so it's unable to prune index entries previously detected as dead, and thus the logic that intends to improve this situation doesn't work on the standby. (I wonder though why, if you executed the same query on the master, its setting of the index-entry-is-dead bits didn't propagate to the standby.) I wonder if we should extend the "SnapshotNonVacuumable" logic introduced in commit 3ca930fc3 so that in hot standby, *all* index entries are deemed non vacuumable. This would essentially get rid of long standby planning times in this sort of scenario by instead accepting worse (possibly much worse) planner range estimates. I'm unsure if that's a good tradeoff or not. regards, tom lane
