Re: limiting hint bit I/O

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: limiting hint bit I/O
Date: 2011-01-14 19:37:52
Message-ID: 4D3051B002000025000395D8@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-01-14 19:44:39 Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.
Previous Message Kevin Grittner 2011-01-14 19:29:53 Re: limiting hint bit I/O