Re: Block write statistics WIP

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: Satoshi Nagayasu <snaga(at)uptime(dot)jp>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Block write statistics WIP
Date: 2013-07-05 07:51:51
Message-ID: 51D67B17.2080203@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 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 greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Meskes 2013-07-05 09:16:44 Re: [9.3 bug fix] ECPG does not escape backslashes
Previous Message Tom Dunstan 2013-07-05 07:51:03 Re: [HACKERS] JPA + enum == Exception