From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Matthew Wakeling <matthew(at)flymine(dot)org> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: I/O on select count(*) |
Date: | 2008-05-19 14:54:06 |
Message-ID: | 200805191454.m4JEs6400890@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Matthew Wakeling wrote:
> On Fri, 16 May 2008, Tom Lane wrote:
> > 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.
>
> Does it really take that long to zero out 8kB of RAM? I thought CPUs were
> really quick at doing that!
Yea, that was my assumption too.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-05-19 15:37:58 | Re: I/O on select count(*) |
Previous Message | Matthew Wakeling | 2008-05-19 12:32:32 | Re: I/O on select count(*) |