From: | Kenneth Marshall <ktm(at)it(dot)is(dot)rice(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <gsstark(at)MIT(dot)EDU>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCHES] ARC Memory Usage analysis |
Date: | 2004-10-25 22:48:30 |
Message-ID: | 20041025224830.GQ12041@it.is.rice.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches pgsql-performance |
On Mon, Oct 25, 2004 at 05:53:25PM -0400, Tom Lane wrote:
> Greg Stark <gsstark(at)MIT(dot)EDU> writes:
> > So I would suggest using something like 100us as the threshold for
> > determining whether a buffer fetch came from cache.
>
> I see no reason to hardwire such a number. On any hardware, the
> distribution is going to be double-humped, and it will be pretty easy to
> determine a cutoff after minimal accumulation of data. The real question
> is whether we can afford a pair of gettimeofday() calls per read().
> This isn't a big issue if the read actually results in I/O, but if it
> doesn't, the percentage overhead could be significant.
>
How invasive would reading the "CPU counter" be, if it is available?
A read operation should avoid flushing a cache line and we can throw
out the obvious outliers since we only need an estimate and not the
actual value.
--Ken
From | Date | Subject | |
---|---|---|---|
Next Message | Pierre-Frédéric Caillaud | 2004-10-25 22:55:38 | Re: copy - fields enclosed by, ignore x lines |
Previous Message | Joshua D. Drake | 2004-10-25 22:47:09 | Re: Lamar stepping down |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-10-25 23:11:05 | Re: [PATCHES] ARC Memory Usage analysis |
Previous Message | Andrew Dunstan | 2004-10-25 22:46:57 | Re: rmtree() failure on Windows |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-10-25 23:11:05 | Re: [PATCHES] ARC Memory Usage analysis |
Previous Message | Tom Lane | 2004-10-25 21:53:25 | Re: [PATCHES] ARC Memory Usage analysis |