Hi~
I did some performance test these days, and I have some findings.
From the archive months ago, I found there were discussions about which type
of TupleTableSlot to use for buffering tuples. A single column mat view was
used for evaluation. Finally we used virtual one.
However when I test with a 32-columns mat view, I get regression.
Test case:
-- prepare
create table test as
select
i as id0,
i + 1 as id1,
i + 2 as id2,
i + 3 as id3,
i + 4 as id4,
i + 5 as id5,
i + 6 as id6,
i + 7 as id7,
i + 8 as id8,
i + 9 as id9,
i + 10 as id10,
i + 11 as id11,
i + 12 as id12,
i + 13 as id13,
i + 14 as id14,
i + 15 as id15,
i + 0.01 as f0,
i + 0.1 as f1,
i + 0.2 as f2,
i + 0.3 as f3,
i + 0.4 as f4,
i + 0.5 as f5,
i + 0.6 as f6,
i + 0.7 as f7,
i + 0.8 as f8,
i + 0.9 as f9,
i + 1.01 as f10,
i + 1.1 as f11,
i + 1.2 as f12,
i + 1.3 as f13,
i + 1.4 as f14,
i + 1.5 as f15,
i + 1.6 as f16
from generate_series(1,5000000) i;
-- run
create materialized view m1 as select * from test;
HEAD:
Time: 13615.542 ms (00:13.616)
Time: 13545.706 ms (00:13.546)
Time: 13578.475 ms (00:13.578)
Patched
Time: 20112.734 ms (00:20.113)
Time: 19996.957 ms (00:19.997)
Time: 19936.871 ms (00:19.937)
I did a quick perf, the overhead seems to come from virtual tuple
materialization.
HEAD:
12.29% postgres [.] pg_checksum_block
6.33% postgres [.] GetPrivateRefCountEntry
5.40% postgres [.] pg_comp_crc32c_sse42
4.54% [kernel] [k] copy_user_enhanced_fast_string
2.69% postgres [.] BufferIsValid
1.52% postgres [.] XLogRecordAssemble
Patched:
11.75% postgres [.] tts_virtual_materialize
8.87% postgres [.] pg_checksum_block
8.17% postgres [.] slot_deform_heap_tuple
8.09% postgres [.] heap_compute_data_size
6.17% postgres [.] fill_val
3.81% postgres [.] heap_fill_tuple
3.37% postgres [.] tts_virtual_copyslot
2.62% [kernel] [k] copy_user_enhanced_fast_string
Not sure if it is a universal situation.
—
Regards, Jingtang
