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: "lars" <lhofhansl(at)yahoo(dot)com>, "Ivan Voras" <ivoras(at)freebsd(dot)org>, pgsql-performance(at)postgresql(dot)org
Subject: Re: UPDATEDs slowing SELECTs in a fully cached database
Date: 2011-07-13 15:17:41
Message-ID: 4752.1310570261@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> ...  Jeff does raise a good point, though -- it seems odd
> that WAL-logging of this pruning would need to be synchronous.

Yeah, we need to get to the bottom of that.  If there's enough
shared_buffer space then it shouldn't be.

> We
> support asynchronous commits -- why not use that feature
> automatically for transactions where the only writes are this sort
> of thing.  Which raises an interesting question -- what happens to
> the timings if your SELECTs are done with synchronous_commit = off?
> I wonder if it would make any sense to implicitly use async commit
> for a transaction which is declared READ ONLY or which never
> acquires and XID?

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

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: larsDate: 2011-07-13 18:10:47
Subject: Re: UPDATEDs slowing SELECTs in a fully cached database
Previous:From: Merlin MoncureDate: 2011-07-13 14:52:53
Subject: Re: UPDATEDs slowing SELECTs in a fully cached database

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