Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

pgsql-performance by date

Next:From: Steinar H. GundersonDate: 2004-10-08 22:39:45
Subject: Re: First set of OSDL Shared Mem scalability results,
Previous:From: Tom LaneDate: 2004-10-08 22:21:28
Subject: Re: First set of OSDL Shared Mem scalability results, some wierdness ...

pgsql-hackers by date

Next:From: Steinar H. GundersonDate: 2004-10-08 22:39:45
Subject: Re: First set of OSDL Shared Mem scalability results,
Previous:From: Tom LaneDate: 2004-10-08 22:21:28
Subject: Re: First set of OSDL Shared Mem scalability results, some wierdness ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group