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

Re: Display Pg buffer cache (WIP)

From: Mark Kirkwood <markir(at)coretech(dot)co(dot)nz>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Display Pg buffer cache (WIP)
Date: 2005-03-05 09:35:42
Message-ID: 42297D6E.3000505@coretech.co.nz (view raw or flat)
Thread:
Lists: pgsql-patches
Neil Conway wrote:
> If you do decide to hold the BufMappingLock, it might make
> sense to:
> 
> 1. allocate an array of NBuffers elements
> 2. acquire BufferMappingLock in share mode
> 3. sequentially scan through the buffer pool, copying data into the array
> 4. release the lock
> 5. on each subsequent call to the SRF, format and return an element of 
> the array
> 
> Which should reduce the time to lock is held. This will require 
> allocating NBuffers * size_of_stats memory (where size_of_stats will be 
> something like 16 bytes).
> 

That is a better approach, so I've used it in this new iteration.

In addition to holding the BufMappingLock, each buffer header is (spin)
locked before examining it, hopefully this is correct - BTW, I like the
new buffer lock design.

I'm still using BuildTupleFromCStrings, so there is considerable use of
sprintf conversion and "temporary" char * stuff. I would like this to be
a bit cleaner, so any suggestions welcome.

regards

Mark



Attachment: pgsql-8.1devel-cachedump2.patch
Description: text/plain (7.4 KB)

In response to

Responses

pgsql-patches by date

Next:From: Ali BabaDate: 2005-03-05 14:03:20
Subject: Exception ERROR Code
Previous:From: Neil ConwayDate: 2005-03-05 09:32:36
Subject: fork() refactoring

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