Re: UPDATEDs slowing SELECTs in a fully cached database

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Ivan Voras" <ivoras(at)freebsd(dot)org>, <pgsql-performance(at)postgresql(dot)org>, "lars" <lhofhansl(at)yahoo(dot)com>
Subject: Re: UPDATEDs slowing SELECTs in a fully cached database
Date: 2011-07-13 21:57:37
Message-ID: 4E1DCE81020000250003F2DC@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Huh? If there was never an XID, there's no commit WAL record,
> hence nothing to make asynchronous.

If you look at the RecordTransactionCommit() function in xact.c
you'll see that's not correct. Currently the commit record has
nothing to do with whether it synchronizes on WAL writes. In
particular, this section around line 1096 is where the choice is
made:

if ((wrote_xlog && synchronous_commit > SYNCHRONOUS_COMMIT_OFF)
|| forceSyncCommit || nrels > 0)
{
/*
* Synchronous commit case:

In the OP's test case, wrote_xlog is true, while forceSyncCommit is
false and nrels == 0.

It doesn't seem like commit of a read-only transaction should be a
magical time for pruning WAL entries to hit the disk, so it probably
would work to modify that "if" to not drop into the synchronous
commit code if the transaction is explicitly declared READ ONLY or
if it never acquired an XID; although there's likely some better way
to deal with it.

-Kevin

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2011-07-13 22:21:17 Re: UPDATEDs slowing SELECTs in a fully cached database
Previous Message Merlin Moncure 2011-07-13 19:01:30 Re: UPDATEDs slowing SELECTs in a fully cached database