Re: First set of OSDL Shared Mem scalability results,

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

In response to

Responses

Browse pgsql-hackers by date

  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 ...

Browse pgsql-performance by date

  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 ...