Re: WIP: avoiding tuple construction/deconstruction overhead

From: a_ogawa <a_ogawa(at)hi-ho(dot)ne(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: WIP: avoiding tuple construction/deconstruction overhead
Date: 2005-03-18 13:17:31
Message-ID: PIEMIKOOMKNIJLLLBCBBEEHJCFAA.a_ogawa@hi-ho.ne.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches


Tom Lane wrote:
> a_ogawa <a_ogawa(at)hi-ho(dot)ne(dot)jp> writes:
> > (1)We can improve compare_heap() by using TableTupleSlot instead of
> > HeapTuple. Please see attached patch.
>
> Did you measure any performance improvement from that? I considered it
> but thought it would likely be a wash or a loss, because in most cases
> only one attribute will be pulled from a tuple during comparetup_heap.
> slot_getattr cannot improve on heap_getattr in that case, and is quite
> likely to be slower.

I measured performance of heap_getattr and slot_getattr in
comparetup_heap.

I made the table which had ten varchar attributes, and registered
data for tests. (Attached file includes SQL doing this.)
I carried out the following tests.

(case 1)
test1: select * from sort_test order by v1 limit 100;
test2: select * from sort_test order by v1, v2 limit 100;
test3: select * from sort_test order by v1, v2, v3 limit 100;
test4: select * from sort_test order by v1, v2, v3, v4 limit 100;
test5: select * from sort_test order by v1, v2, v3, v4, v5 limit 100;

result: test1 test2 test3 test4 test5
-----------------------------------------------------------------------
heap_getattr 2.149s 2.602s 3.204s 3.830s 4.159s
slot_getattr 2.523s 3.422s 3.977s 4.453s 4.721s

(case 2)
test1: select * from sort_test order by v10 limit 100;
test2: select * from sort_test order by v10, v9 limit 100;
test3: select * from sort_test order by v10, v9, v8 limit 100;
test4: select * from sort_test order by v10, v9, v8, v7 limit 100;
test5: select * from sort_test order by v10, v9, v8, v7, v6 limit 100;

result: test1 test2 test3 test4 test5
-----------------------------------------------------------------------
heap_getattr 3.654s 5.549s 6.575s 7.367s 7.870s
slot_getattr 4.027s 4.930s 5.249s 5.555s 5.756s

(case 3)
test1: select * from sort_test order by v5 limit 100;
test2: select * from sort_test order by v5, v6 limit 100;
test3: select * from sort_test order by v5, v6, v7 limit 100;
test4: select * from sort_test order by v5, v6, v7, v8 limit 100;
test5: select * from sort_test order by v5, v6, v7, v8, v9 limit 100;

result: test1 test2 test3 test4 test5
-----------------------------------------------------------------------
heap_getattr 2.657s 4.207s 5.194s 6.179s 6.662s
slot_getattr 3.126s 4.233s 4.806s 5.271s 5.557s

In most cases, heap_getattr is fast.
When the following conditions occurred, slot_getattr is fast.
(1)Tuple have varlen attributes.
(2)Sort key have more than two attributes.
(3)A position of a sort key is far from the head of tuple.
(4)As for the data of a sort key, there be many repetition.
Actually it will be rare that these conditions are occurred.

Thinking from a result, I think that we had better continue using
heap_getattr in comparetup_heap.

regards,

--- Atsushi Ogawa

Attachment Content-Type Size
make_test_data.sql application/octet-stream 689 bytes

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2005-03-18 17:19:12 Re: WIP: avoiding tuple construction/deconstruction overhead
Previous Message Cosimo Streppone 2005-03-18 11:40:53 pg_autovacuum micro patch to display database name when ANALYZEing or VACUUMing tables