Re: Does TupleQueueReaderNext() really need to copy its result?

On Thu, Aug 22, 2019 at 12:08 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> Given that shm_mq.c proudly documents that it avoids copying the data
> on the receiving side (unless it has to reconstruct a message that was
> split up), and given that it promises that the pointed-to data remains
> valid until your next call, it seems that it should be safe to return
> a pointer to the same HeapTupleData object every time (perhaps a
> member of the TupleQueueReader struct) and just adjust its t_data and
> t_len members every time, so that the gather node emits tuples
> directly from the shared memory queue (and then of course tell the
> slot not to pfree()).  Alternatively, if the value returned by
> shm_mq_receive() is not really suitably aligned, then the comment is a
> bit misleading.

Couldn't resist trying this, and it seems to work.  Based on the
comment "the buffer size is a multiple of MAXIMUM_ALIGNOF, and each
read and write is as well", it should always work (though I wish
shm_mq_receive_bytes()'s documentation would discuss message alignment
explicitly if that's true).  On the other hand, I doubt it makes a
difference, so this is more of a question: is this the way it was
supposed to work?

(It was ~40% faster at shunting a large SELECT * through the queue
with asserts enabled, which made me happy for moment, but it was only
an illusion and not measurable in the noise without asserts).

-- 
Thomas Munro
https://enterprisedb.com