On Sun, Jun 10, 2018 at 1:19 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Maksim Milyutin <milyuti...@gmail.com> 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, >
I don't see anything like that in the code. We use _bt_killitems to mark the items as dead and neither that function or any of its caller has any such assumption. > 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. > If my above understanding is correct, then one thing that could lead to such behavior is the computation of RecentGlobalXmin on standby. Basically, if the RecentGlobalXmin has a different value on standby, then it is possible that the decision whether a particular item is dead differs on master and 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.) > Because we don't WAL log it. See _bt_killitems. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
