On Thu, Aug 22, 2019 at 12:08 PM Thomas Munro <thomas.mu...@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
0001-Avoid-unnecessary-copying-in-tqueue.c.patch
Description: Binary data
