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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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 Content-Type Size
pgsql-8.1devel-cachedump2.patch text/plain 7.4 KB

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Ali Baba 2005-03-05 14:03:20 Exception ERROR Code
Previous Message Neil Conway 2005-03-05 09:32:36 fork() refactoring