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
Hi,
I'm looking into this patch as a reviewer.
(2013/05/24 10:33), Heikki Linnakangas wrote:
On 23.05.2013 19:10, Greg Smith wrote:
On 5/20/13 7:51 AM, Heikki Linnakangas wrote:
It strikes me as kind of weird that the read side and write side are
not more symmetrical.
It might seem weird if
On 5/20/13 7:51 AM, Heikki Linnakangas wrote:
The way that MarkDirty requires this specific underlying storage manager
behavior to work properly strikes me as as a bit of a layering violation
too. I'd like the read and write paths to have a similar API, but here
they don't even operate on the
On 23.05.2013 19:10, Greg Smith wrote:
On 5/20/13 7:51 AM, Heikki Linnakangas wrote:
The way that MarkDirty requires this specific underlying storage
manager behavior to work properly strikes me as as a bit of a
layering violation too. I'd like the read and write paths to have
a similar API,
On 19.05.2013 11:15, Greg Smith wrote:
I've thought of two paths to get a block write count out of that so far:
-Provide a function to find the Relation from the RelFileNode. There is
a warning about the perils of assuming you can map that way from a
buftag value in buf_internals.h though:
I have some time now for working on the mystery of why there are no
block write statistics in the database. I hacked out the statistics
collection and reporting side already, rough patch attached if you want
to see the boring parts.
I guessed that there had to be a gotcha behind why this
