From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Portability issues in shm_mq |
Date: | 2014-03-18 14:44:08 |
Message-ID: | 8677.1395153848@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Mar 17, 2014 at 11:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Would it get noticeably simpler or faster if you omitted support for
>> the sizeof(Size) > MAXIMUM_ALIGNOF case? It looks like perhaps not,
>> but if we were paying anything much I'd be tempted to just put in
>> a static assert to the contrary and see if anyone complains.
> Not really. I installed a fast path into the receive code for the
> common case where the length word isn't split, which will always be
> true on platforms where sizeof(Size) <= MAXIMUM_ALIGNOF and usually
> true otherwise. We could ditch the slow path completely by ignoring
> that case, but it's not all that much code. On the sending side, the
> logic is pretty trivial, so I definitely don't feel bad about carrying
> that.
Works for me.
> The thing I kind of like about this approach is that it makes the code
> fully independent of the relationship between MAXIMUM_ALIGNOF and
> sizeof(Size).
Yeah. If it's not costing us much to support both cases, let's do so.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-03-18 14:47:33 | Re: GSoC proposal. Index-only scans for GIST |
Previous Message | Robert Haas | 2014-03-18 14:35:16 | Re: Portability issues in shm_mq |