Re: synchronous commit vs. hint bits

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: synchronous commit vs. hint bits
Date: 2011-11-07 14:45:09
Message-ID: CA+TgmobjN3k7GMFLvhF=a5oFheu2UmQ+gba19L5LLH2Z+K=Grw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 7, 2011 at 9:31 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> So, what could we do about this?  Ideas:
>
> 1. Set the hint bits right away, and avoid letting the page be flushed
> to disk until the commit record is durably on disk (by bumping the
> page LSN?).
> 2. Improve CLOG concurrency or performance in some way so that
> consulting it repeatedly doesn't slow us down so much.
> 3. Do more backend-private XID status caching - in particular, for
> commits, since this isn't a problem for aborts.
> 4. (Crazy idea) Have something that's like a hint bit, but stored in
> the buffer header rather than the data block itself.  We allocate an
> array large enough to hold 2 bits per tuple (for the maximum number of
> tuples that can exist on a page), with one bit indicating that xmin is
> async-committed and the other indicating that xmax is async-committed.
>
> There are probably other options as well.

5. Make the WAL writer more responsive, maybe using latches, so that
it doesn't take as long for the commit record to make it out to disk.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-11-07 15:07:50 Re: -Wcast-qual cleanup, part 1
Previous Message Kevin Grittner 2011-11-07 14:40:11 Re: git trunk doesn't build