Re: Block write statistics WIP - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Block write statistics WIP
Date
Msg-id 51D67B17.2080203@2ndQuadrant.com
Whole thread Raw
In response to Re: Block write statistics WIP  (Satoshi Nagayasu <snaga@uptime.jp>)
List pgsql-hackers
On 7/1/13 3:10 AM, Satoshi Nagayasu wrote:
> Or should we add some pointer, which is accociated with the Relation,
> into BufferDesc? Maybe OID?

That is the other option here, I looked at it but didn't like it.  The 
problem is that at the point when a new page is created, it's not always 
clear yet what relation it's going to hold.  That means that if the 
buffer page itself is where you look up the relation OID, every code 
path that manipulates relation IDs will need to worry about maintaining 
this information.  It's possible to do it that way, but I don't know 
that it's any less work than making all the write paths keep track of 
it.  It would need some extra locking around updating the relation tag 
in the buffer pages too, and I'd prefer not to

The other thing that I like about the writing side is that I can 
guarantee the code is correct pretty easily.  Yes, it's going to take 
days worth of modifying writing code.  But the compile will force you to 
fix all of them, and once they're all updated I'd be surprised if 
something unexpected happened.

If instead the data moves onto the buffer page header instead, we could 
be chasing bugs similar to the relcache ones forever.  Also, as a tie 
breaker, buffer pages will get bigger and require more locking this way.  Making writers tell us the relation doesn't
needany of that.
 

> I'm thinking of FlushBuffer() too. How can we count physical write
> for each relation in FlushBuffer()? Or any other appropriate place?

SMgrRelation is available there, so tagging the relation should be easy 
in this case.

> BTW, Greg's first patch could not be applied to the latest HEAD.
> I guess it need to have some fix, I couldn't clafiry it though.

Since this is a WIP patch, what I was looking for was general design 
approach feedback, with my bit as a simple example.  I didn't expect 
anyone to spend much time doing a formal review of that quick hack. 
You're welcome to try and play with that code to add things, I'm not 
very attached to it yet.  I've basically gotten what I wanted to here 
from this submission; I'm marking it returned with feedback.  If anyone 
else has comments, I'm still open to discussion here too.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: KONDO Mitsumasa
Date:
Subject: Re: Improvement of checkpoint IO scheduler for stable transaction responses
Next
From: Michael Meskes
Date:
Subject: Re: [9.3 bug fix] ECPG does not escape backslashes