Re: Early hint bit setting - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Early hint bit setting
Date
Msg-id CA+TgmoaMLYg43RugcQ52f6gkURQ+JTnoGP-kGcZW907KZDYT_Q@mail.gmail.com
Whole thread Raw
In response to Re: Early hint bit setting  (Jim Nasby <jim@nasby.net>)
List pgsql-hackers
On Wed, Jun 6, 2012 at 6:41 PM, Jim Nasby <jim@nasby.net> wrote:
> Except that's only true when there are no other transactions running. That's
> been one of the big sticking points about trying to proactively set hint
> bits; in a real system you're not going to gain very much unless you wait a
> while before setting them.

No, the committed hint bit just means that the transaction is
committed.  You don't have to wait for it to be all-visible.

I think my biggest concern about this is that it inevitably relies on
some assumption about how much latency there will be before the client
sends the next request.  That strikes me as impossible to tune.  On
system A, connected to the Internet via an overloaded 56k modem link,
you can get away with doing a huge amount of fiddling around while
waiting for the next request.  But on system B, which uses 10GE or
Infiniband or local sockets, the acceptable latency will be much less.Even given identical hardware, scheduler behavior
maymatter quite a
 
lot - rumor has it that FreeBSD's scheduling latency may be
significantly less than on Linux, although I have not verified it and
rumor may lie.  But the point is that whether or not this works out to
a win on any given system seems like it will depend on an awful lot of
stuff that we can't know or control.

I would be more inclined to look at trying to make this happen in a
background process, although that's not without its own challenges.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: XLog changes for 9.3
Next
From: Robert Haas
Date:
Subject: Re: XLog changes for 9.3