Re: limiting hint bit I/O - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: limiting hint bit I/O
Date
Msg-id 4D3051B002000025000395D8@gw.wicourts.gov
Whole thread Raw
In response to Re: limiting hint bit I/O  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: limiting hint bit I/O  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> wrote:
> The critical issue is whether the tuples get frozen while they're
> still invisible to some transactions on the standby server. 
> That's when you get query cancellations.
Oh, OK; I get that.  That seems easy enough to at least mitigate to
a large degree by some threshold GUC.  But of course, the longer you
wait to freeze so that you don't cancel queries on the standby, the
more you pay to recalculate visibility, so it'd be a fussy thing to
tune.  Perhaps such freeze information could be queued until a safe
time on the standby.  (Now that I've learned the joys of SLRU, I can
see all sorts of possible uses for it....)
> Well, let me put together a quick patch that obliterates hint bits
> entirely, and we can measure that.  The background writer has
> always pushed out hint bit pages; I think the reduced performance
> was probably due to needing to reset hint bits on pages that we
> threw away without pushing them out.
It would be good to confirm and quantify.
-Kevin


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: limiting hint bit I/O
Next
From: Robert Haas
Date:
Subject: Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.