Re: UPDATEDs slowing SELECTs in a fully cached database - Mailing list pgsql-performance

From Tom Lane
Subject Re: UPDATEDs slowing SELECTs in a fully cached database
Date
Msg-id 4752.1310570261@sss.pgh.pa.us
Whole thread Raw
In response to Re: UPDATEDs slowing SELECTs in a fully cached database  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: UPDATEDs slowing SELECTs in a fully cached database  (lars <lhofhansl@yahoo.com>)
Re: UPDATEDs slowing SELECTs in a fully cached database  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-performance
"Kevin Grittner" <Kevin.Grittner@wicourts.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

pgsql-performance by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: UPDATEDs slowing SELECTs in a fully cached database
Next
From: lars
Date:
Subject: Re: UPDATEDs slowing SELECTs in a fully cached database