On Wed, Oct 1, 2014 at 4:56 PM, Stephen Frost <sfrost@snowman.net> wrote:
> * Robert Haas (robertmhaas@gmail.com) wrote:
>> On Mon, Sep 29, 2014 at 12:05 PM, Stephen Frost <sfrost@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