Re: Early hint bit setting

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jim Nasby <jim(at)nasby(dot)net>
Cc: Ants Aasma <ants(at)cybertec(dot)at>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Early hint bit setting
Date: 2012-06-07 17:40:49
Message-ID: CA+TgmoaMLYg43RugcQ52f6gkURQ+JTnoGP-kGcZW907KZDYT_Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 6, 2012 at 6:41 PM, Jim Nasby <jim(at)nasby(dot)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 may matter 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Lonni J Friedman 2012-06-07 17:41:36 pg_basebackup blocking all queries with horrible performance
Previous Message Kevin Grittner 2012-06-07 17:40:20 Re: XLog changes for 9.3