On Tue, Mar 16, 2021 at 4:07 PM Dilip Kumar <dilipbal...@gmail.com> wrote:
>
> INSERT TIME
> Head: 17418.299 ms Patch: 20956.231 ms
>
> CTAS TIME:
> Head: 12837.872 ms Patch: 16775.739 ms
On quick analysis with perf it appeared that the performance is
degrading because of deforming
- 16.19% 3.54% postgres postgres [.]
CompareCompressionMethodAndDecompress
- 12.65% CompareCompressionMethodAndDecompress
- 12.57% slot_getallattrs
- 12.56% slot_getsomeattrs
- 12.53% slot_getsomeattrs_int
- 12.50% tts_buffer_heap_getsomeattrs
slot_deform_heap_tuple
So I think in the case of direct insert it needs to deform because I
am calling CompareCompressionMethodAndDecompress after ExecCopySlot
and that is why we have to deform every time so maybe that can be
avoided by calling CompareCompressionMethodAndDecompress before
ExecCopySlot. But in the case of CTAS or INSERT INTO SELECT we can
not avoid deforming because we might get the formed tuple from the
source table. I put a temporary hack to keep the map of the varlena
attribute and use it across the tuple but it did not improve the
performance in this case because the main bottleneck is
slot_getallattrs. I think this should help where we don't have any
varlena, but first I need to test whether we can any performance
regression in those cases at all.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
