Re: Block write statistics WIP - Mailing list pgsql-hackers
From | Heikki Linnakangas |
---|---|
Subject | Re: Block write statistics WIP |
Date | |
Msg-id | 519EC362.8080008@vmware.com Whole thread Raw |
In response to | Re: Block write statistics WIP (Greg Smith <greg@2ndQuadrant.com>) |
Responses |
Re: Block write statistics WIP
(Satoshi Nagayasu <snaga@uptime.jp>)
|
List | pgsql-hackers |
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, but here they don't even operate on the same type >>> of inputs. Addressing that is probably harder than just throwing >>> a hack on the existing code though. >> >> To be honest, I don't understand what you mean by that. ? > > Let's say you were designing a storage layer API from scratch for > what Postgres does. That might take a relation as its input, like > ReadBuffer does. Hiding the details of how that turns into a physical > file operation would be a useful goal of such a layer. I'd then > consider it a problem if that exposed things like the actual mapping > of relations into files to callers. Ok, got it. > What we actually have right now is this MarkDirty function that > operates on BufferTag data, which points directly to the underlying > file. I see that as cutting the storage API in half and calling a > function in the middle of the implementation. Well, no, the BufferTag struct is internal to the buffer manager implementation. It's not part of the API; it's an implementation detail of the buffer manager. > It strikes me as kind of weird that the read side and write side are > not more symmetrical. It might seem weird if you expect the API to be similar to POSIX read() and write(), where you can read() an arbitrary block at any location, and write() an arbitrary block at any location. A better comparison would be e.g open() and close(). open() returns a file descriptor, which you pass to other functions to operate on the file. When you're done, you call close(fd). The file descriptor is completely opaque to the user program, you do all the operations through the functions that take the fd as argument. Similarly, ReadBuffer() returns a Buffer, which is completely opaque to the caller, and you do all the operations through various functions and macros that operate on the Buffer. When you're done, you release the buffer with ReleaseBuffer(). (sorry for the digression from the original topic, I don't have any problem with what adding an optional Relation argument to MarkBuffer if you need that :-) ) - Heikki
pgsql-hackers by date: