Re: I/O on select count(*) - Mailing list pgsql-performance

From Tom Lane
Subject Re: I/O on select count(*)
Date
Msg-id 18382.1210992302@sss.pgh.pa.us
Whole thread Raw
In response to Re: I/O on select count(*)  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: I/O on select count(*)  (Jeremy Harris <jgh@wizmail.org>)
Re: I/O on select count(*)  (Greg Smith <gsmith@gregsmith.com>)
Re: I/O on select count(*)  (Matthew Wakeling <matthew@flymine.org>)
List pgsql-performance
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Greg Smith wrote:
>> After reading the code and that documentation a bit, the part I'm still
>> not sure about is whether the CLOG entry is created when the XID is
>> assigned and then kept current as the state changes, or whether that
>> isn't even in CLOG until the transaction is committed.

> pg_clog is allocated in pages of 8kB apiece(*).  On allocation, pages are
> zeroed, which is the bit pattern for "transaction in progress".  So when
> a transaction starts, it only needs to ensure that the pg_clog page that
> corresponds to it is allocated, but it need not write anything to it.

One additional point: this means that one transaction in every 32K
writing transactions *does* have to do extra work when it assigns itself
an XID, namely create and zero out the next page of pg_clog.  And that
doesn't just slow down the transaction in question, but the next few
guys that would like an XID but arrive on the scene while the
zeroing-out is still in progress.

This probably contributes to the behavior that Simon and Josh regularly
complain about, that our transaction execution time is subject to
unpredictable spikes.  I'm not sure how to get rid of it though.

            regards, tom lane

pgsql-performance by date:

Previous
From: "Scott Marlowe"
Date:
Subject: Re: Regexps - never completing join.
Next
From: Jeremy Harris
Date:
Subject: Re: I/O on select count(*)