Index-only scan is slower than Index scan.

Hi hackers,

One of our customers noticed strange thing: time of execution of the 
same query is about 25% slower with index only scan, comparing with 
indexscan plan
(produced with enable_indexonlyscan = off).
The query is the following:

SELECT
     T1._Period,
     T1._RecorderTRef,
     T1._RecorderRRef,
     T1._LineNo,
     T1._Correspond,
     T1._KindRRef,
     T1._Value_TYPE,
     T1._Value_RTRef,
     T1._Value_RRRef
     FROM _AccRgED165 T1
     WHERE (T1._KindRRef = 
'\\217\\246\\000\\011\\017\\252\\000\\001\\021\\350 
\\204K\\226\\335\\225'::bytea) AND (T1._Value_TYPE = '\\010'::bytea AND 
T1._Value_RTRef = '\\000\\000\\000\\033'::bytea AND T1._Value_RRRef = 
'\\217\\246\\000\\011\\017\\252\\000\\001\\021\\350 
\\202O\\375/\\317'::bytea) AND ((T1._Period >= '2017-08-01 
00:00:00'::timestamp) AND (T1._Period <= '2017-09-01 00:00:00'::timestamp))
     ;

Most of the fetched fields have "bytea" type, so their offsets are not 
cached in tuple descriptor.
StoreIndexTuple in nodeIndexonlyscan.c is using index_getattr to 
extract  index tuple components.
As far as fields offset can not be cached, we have to scan i-1 preceding 
attributes to fetch i-th attribute.
So StoreIndexTuple has quadratic complexity of number of attributes. In 
this query there are 9 attributes and it is enough to make
index only scan 25% slower than Index scan, because last one is 
extracting all attributes from heap tuple using slot_getsomeattrs() 
function.

I have replaced loop extracting  attributes using index_getattr() in 
StoreIndexTuple with invocation of index_deform_tuple()
and reimplemented last one in the same way as heap_deform_tuple (extract 
all attributes in one path).
My small patch is attached to this mail. After applying it index-only 
scan takes almost the same time as index scan:


index scan 	1.995
indexonly scan (original) 	2.686
indexonly scan (patch) 	2.005



-- 
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company