Re: BUG #14635: Query is executed slower on hot standby slave database then on master database

On Mon, May 15, 2017 at 5:41 PM, Vitaliy Gomenyuk
<vgomenyuk(at)callfire(dot)com> wrote:
> On Fri, May 12, 2017 at 8:30 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>
>> On Thu, May 4, 2017 at 10:26:17AM +1000, Haribabu Kommi wrote:
>> > The contents of the indexes should be the same, so why is the slave
>> > returning so many more rows? It has to be because the index entries are
>> > not marked as killed (known-dead-to-everybody), or not being treated as
>> > killed, in the slave. I vaguely recall that there's a difference in the
>> > rules for index entry visibility on slaves, but it's not clear to me why
>> > that should be.
>> >
>> >
>> > The index cleanup by the full vacuum and vacuum one page are WAL logged,
>> > so when they gets replayed on the slave, both the indexes must be same.
>> >
>> > May be the WAL didn't replayed on the slave because of conflict transaction?
>> > Or Any other scenarios it may be different?
>>
>> We don't WAL-log hint bits. Could that affect queries running on the
>> standbys?
>
> What does it mean "We don't WAL-log hint bits"?

(Please avoid top-posting...)

Haribaru has given upthread an answer good enough for that. Here are
more details...

Here is a description about what are hint bits:
https://wiki.postgresql.org/wiki/Hint_Bits

This sentence means that no WAL records are generated when a hint bit
is updated on a page. There are circumstances where setting up a hint
bit on a page causes WAL activity though: if wal_log_hints is enabled,
if a hint bit is the first update happening on a page, then a WAL
record to log a full page write of this page is taken.
--
Michael