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 need any 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 g...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
