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