On Wed, Oct 1, 2014 at 4:56 PM, Stephen Frost <sfr...@snowman.net> wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Mon, Sep 29, 2014 at 12:05 PM, Stephen Frost <sfr...@snowman.net> wrote: >> > Perhaps I'm just being a bit over the top, but all this per-character >> > work feels a bit ridiculous.. When we're using MAXIMUM_ALIGNOF, I >> > suppose it's not so bad, but is there no hope to increase that and make >> > this whole process more efficient? Just a thought. >> >> I'm not sure I understand what you're getting at here. > > Was just thinking that we might be able to work out what needs to be > done without having to actually do it on a per-character basis. That > said, I'm not sure it's really worth the effort given that we're talking > about at most 8 bytes currently. I had originally been thinking that we > might increase the minimum size as it might make things more efficient, > but it's not clear that'd really end up being the case either and, > regardless, it's probably not worth worrying about at this point.
I'm still not entirely sure we're on the same page. Most of the data movement for shm_mq is done via memcpy(), which I think is about as efficient as it gets. The detailed character-by-character handling only really comes up when shm_mq_send() is passed multiple chunks with lengths that are not a multiple of MAXIMUM_ALIGNOF. Then we have to fiddle a bit more. So making MAXIMUM_ALIGNOF bigger would actually cause us to do more fiddling, not less. When I originally designed this queue, I had the idea in mind that life would be simpler if the queue head and tail pointers always advanced in multiples of MAXIMUM_ALIGNOF. That didn't really work out as well as I'd hoped; maybe I would have been better off having the queue pack everything in tightly and ignore alignment. However, there is some possible efficiency advantage of the present system: when a message fits in the queue without wrapping, shm_mq_receive() returns a pointer to the message, and the caller can assume that message is properly aligned. If the queue didn't maintain alignment internally, you'd need to do a copy there before accessing anything inside the message that might be aligned. Granted, we don't have any code that takes advantage of that yet, at least not in core, but the potential is there. Still, I may have made the wrong call. But, I don't think it's the of this patch to rework the whole framework; we can do that in the future after this has a few more users and the pros and cons of various approaches are (hopefully) more clear. It's not a complex API, so substituting a different implementation later on probably wouldn't be too hard. Anyway, it sounds like you're on board with me committing the first patch of the series, so I'll do that next week absent objections. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
