From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "J(dot) Andrew Rogers" <jrogers(at)neopolitan(dot)com> |
Cc: | josh(at)agliodbs(dot)com, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: First set of OSDL Shared Mem scalability results, |
Date: | 2004-10-08 22:32:32 |
Message-ID: | 21489.1097274752@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
"J. Andrew Rogers" <jrogers(at)neopolitan(dot)com> writes:
> As I understand it (and I haven't looked so I could be wrong), the
> buffer cache is searched by traversing it sequentially.
You really should look first.
The main-line code paths use hashed lookups. There are some cases that
do linear searches through the buffer headers or the CDB lists; in
theory those are supposed to be non-performance-critical cases, though
I am suspicious that some are not (see other response). In any case,
those structures are considerably more compact than the buffers proper,
and I doubt that cache misses per se are the killer factor.
This does raise a question for Josh though, which is "where's the
oprofile results?" If we do have major problems at the level of cache
misses then oprofile would be able to prove it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Steinar H. Gunderson | 2004-10-08 22:39:45 | Re: First set of OSDL Shared Mem scalability results, |
Previous Message | Tom Lane | 2004-10-08 22:21:28 | Re: First set of OSDL Shared Mem scalability results, some wierdness ... |
From | Date | Subject | |
---|---|---|---|
Next Message | Steinar H. Gunderson | 2004-10-08 22:39:45 | Re: First set of OSDL Shared Mem scalability results, |
Previous Message | Tom Lane | 2004-10-08 22:21:28 | Re: First set of OSDL Shared Mem scalability results, some wierdness ... |