I have been looking at PostgreSQL's Tuple Queue
(/include/executor/tqueue.h) which provides functionality for queuing
tuples between processes through shm_mq. I am still familiarising myself
with the bigger picture and TupTableStores. I can see that a copy (not a
reference) of a HeapTuple (obtained from TupleTableSlot or SPI_TupTable
etc) can be sent to a queue using shm_mq. Then, another process can
receive these HeapTuples, probably later placing them in 'output'
TupleTableSlots.
What I am having difficulty understanding is what happens to the
location of the HeapTuple as it moves from one TupleTableSlot to the
other as described above. Since there most likely is a reference to a
physical tuple involved, am I incurring a disk-access overhead with each
copy of a tuple? This would seem like a massive overhead; how can I keep
such overheads to a minimum?
Furthermore, to what extent can I expect other modules to impact a
queued HeapTuple? If some external process updates this tuple, when will
I see the change? Would it be a possiblity that the update is not
reflected on the queued HeapTuple but the external process is not
blocked/delayed from updating? In other words, like operating on some
kind of multiple snapshots? When does DBMS logging kick in whilst I am
transferring a tuple from TupTableStore to another?
Thanks,
Tom