Skip site navigation (1) Skip section navigation (2)

Re: UPDATEDs slowing SELECTs in a fully cached database

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
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 22:21:17
Message-ID: 11679.1310595677@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> 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.

Oh, hmmm ... that code was written with the idea that things like
sequence XLOG_SEQ_LOG records ought to be flushed to disk before
reporting commit; otherwise you don't have a guarantee that the same
sequence value couldn't be handed out again after crash/restart,
in a transaction that just does something like
	SELECT nextval('myseq');
without any updates of regular tables.

It seems like we ought to distinguish heap cleanup activities from
user-visible semantics (IOW, users shouldn't care if a HOT cleanup has
to be done over after restart, so if the transaction only wrote such
records there's no need to flush).  This'd require more process-global
state than we keep now, I'm afraid.

Another approach we could take (also nontrivial) is to prevent
select-only queries from doing HOT cleanups.  You said upthread that
there were alleged performance benefits from aggressive cleanup, but
IMO that can charitably be described as unproven.  The real reason it
happens is that we didn't see a simple way for page fetches to know soon
enough whether a tuple update would be likely to happen later, so they
just do cleanups unconditionally.

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: larsDate: 2011-07-13 22:41:16
Subject: Re: UPDATEDs slowing SELECTs in a fully cached database
Previous:From: Kevin GrittnerDate: 2011-07-13 21:57:37
Subject: Re: UPDATEDs slowing SELECTs in a fully cached database

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group