I have made a small research and found out that though the patch itself is correct (i.e. we can benefit from replacing TTSOpsMinimalTuple with TTSOpsVirtual for the Unique node), my explanation WHY was wrong.
1. We always materialize the new unique tuple in the slot, never mind what type of tuple table slots do we use.
2. But the virtual tuple materialization (tts_virtual_copyslot) have performance benefits over the minimal tuple one (tts_minimal_copyslot):
- tts_minimal_copyslot always allocates zeroed memory with palloc0 (expensive according to the flame graph);
- tts_minimal_copyslot() doesn’t allocate additional memory if the tuples are constructed from the passed by value column (but for the variable-size columns we still need memory allocation);
- if tts_minimal_copyslot() need allocation it doesn’t need to zero the memory;
So as a result we seriously benefit from virtual TTS for the tuples constructed from the fixed-sized columns when get a Unique node in the plan.
31 авг. 2023 г., в 10:28, Denis Smirnov <darthunix@gmail.com> написал(а):
It looks like my patch was not analyzed by the hackers mailing list due to incorrect mime type, so I duplicate it here.
<v2-use-virtual-slots-for-unique-node.patch.txt>31 авг. 2023 г., в 10:06, Denis Smirnov <darthunix@gmail.com> написал(а):
<v2-use-virtual-slots-for-unique-node.patch.txt>
