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

From Kevin Grittner
Subject Re: limiting hint bit I/O
Date
Msg-id 4D3042C302000025000395B5@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  (Robert Haas <robertmhaas@gmail.com>)
Re: limiting hint bit I/O  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> wrote:
> I'm hoping some will pick it up and play with it some more (hint,
> hint).
That was a bit of a pun, eh?
Anyway, there are so many ideas in this area, it's hard to keep them
all straight.  Personally, if I was going to start with something,
it would probably be to better establish what the impact is on
various workloads of *eliminating* hint bits.  If the impact is
negative to a significant degree, my next step might be to try
background *freezing* of tuples (in a manner somewhat similar to
what you've done in this test) with the hint bits gone.
I know some people find them useful for forensics to a degree that
they would prefer not to see this, but I think it makes sense to
establish what cost people are paying every day to maintain forensic
information in this format.  In previous discussions there has been
some talk about being able to get better forensics from WAL files if
certain barriers could be overcome -- having hard numbers on the
performance benefits which might also accrue might put that work in
a different perspective.
-Kevin


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: limiting hint bit I/O
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.