Re: [BUGS] BUG #14635: Query is executed slower on hot standby slavedatabase then on master database

On Mon, May 15, 2017 at 5:41 PM, Vitaliy Gomenyuk
<vgomenyuk@callfire.com> wrote:
> On Fri, May 12, 2017 at 8:30 PM, Bruce Momjian <bruce@momjian.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


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs