Re: Identity projection - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: Identity projection
Date
Msg-id 20121005.160416.256387378.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: Identity projection  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: Identity projection
Re: Identity projection
List pgsql-hackers
Hello, sorry for long absense,

#  I had unexpected and urgent time-consuming tasks... :-(

I have had a bit more precise inspection by two aspects, and they
seemd showing that the difference should be the execution time of
ExecProject.

I'll be able to back fully next week with reviesed patch, and to
take some other pathes to review...


============
> Although I said as following, the gain seems a bit larger... I'll
> recheck the testing conditions...

I had inspected more precisely on two aspects maginifying the
effect of this patch by putting 300 columns into table.


First, explain analyze says the difference caused by this patch
is only in the actual time of Result node.

orig$ psql -c 'explain analyze select * from parenta'                         QUERY PLAN
--------------------------------------------------------------------------Result  (cost=0.00..176667.00 rows=1000001
width=1202)       (actual time=0.013.. *2406.792* rows=1000000 loops=1)  ->  Append  (cost=0.00..176667.00 rows=1000001
width=1202)             (actual time=0.011..412.749 rows=1000000 loops=1)        ->  Seq Scan on parenta
(cost=0.00..0.00rows=1 width=1228)                                 (actual time=0.001..0.001 rows=0 loops=1)        ->
SeqScan on childa000 parenta                           (cost=0.00..176667.00 rows=1000000 width=1202)
       (actual time=0.009..334.633 rows=1000000 loops=1)Total runtime: 2446.474 ms
 
(5 rows)

patched$ psql -c 'explain analyze select * from parenta'                         QUERY PLAN
--------------------------------------------------------------------------Result  (cost=0.00..176667.00 rows=1000001
width=1202)       (actual time=0.011.. *507.239* rows=1000000 loops=1)  ->  Append  (cost=0.00..176667.00 rows=1000001
width=1202)             (actual time=0.011..419.420 rows=1000000 loops=1)        ->  Seq Scan on parenta
(cost=0.00..0.00rows=1 width=1228)                                 (actual time=0.000..0.000 rows=0 loops=1)        ->
SeqScan on childa000 parenta                           (cost=0.00..176667.00 rows=1000000 width=1202)
       (actual time=0.010..335.721 rows=1000000 loops=1)Total runtime: 545.879 ms
 
(5 rows)

Second, the results of configure --enable-profiling shows that
the exectime of ExecProject chages greately. This is consistent
with what explain showed.

orig:>  %   cumulative   self              self     total           > time   seconds   seconds    calls   s/call
s/call name    > 60.29      1.26     1.26  1000005     0.00     0.00  slot_deform_tuple
 
!> 30.14      1.89     0.63  1000000     0.00     0.00  ExecProject>  3.35      1.96     0.07  3000004     0.00
0.00 ExecProcNode>  0.96      1.98     0.02  1000002     0.00     0.00  ExecScan>  0.96      2.00     0.02   166379
0.00    0.00  TerminateBufferIO>  0.48      2.01     0.01  3000004     0.00     0.00  InstrStartNode>  0.48      2.02
 0.01  3000004     0.00     0.00  InstrStopNode
 
!>  0.48      2.03     0.01  1000001     0.00     0.00  ExecResult>  0.48      2.04     0.01   830718     0.00     0.00
LWLockAcquire>  0.48      2.05     0.01   506834     0.00     0.00  hash_search_with_hash_value>  0.48      2.06
0.01  341656     0.00     0.00  LockBuffer>  0.48      2.07     0.01   168383     0.00     0.00  ReadBuffer_common>
0.48     2.08     0.01        4     0.00     0.00  InstrEndLoop>  0.48      2.09     0.01
ExecCleanTargetListLength> 0.00      2.09     0.00  2000005     0.00     0.00  MemoryContextReset
 

patched:>   %   cumulative   self              self     total           >  time   seconds   seconds    calls  ms/call
ms/call name    >  23.08      0.03     0.03  3000004     0.00     0.00  ExecProcNode>  15.38      0.05     0.02
1000002    0.00     0.00  heapgettup_pagemode>  15.38      0.07     0.02   830718     0.00     0.00  LWLockAcquire>
7.69     0.08     0.01  2000005     0.00     0.00  MemoryContextReset>   7.69      0.09     0.01  1000002     0.00
0.00 ExecScan>   7.69      0.10     0.01  1000000     0.00     0.00  ExecStoreTuple>   7.69      0.11     0.01   841135
   0.00     0.00  LWLockRelease>   7.69      0.12     0.01   168383     0.00     0.00  ReadBuffer_common>   7.69
0.13    0.01   168383     0.00     0.00  UnpinBuffer>   0.00      0.13     0.00  3000004     0.00     0.00
InstrStartNode...
!>   0.00      0.13     0.00  1000001     0.00     0.00  ExecResult
!>   0.00      0.13     0.00  1000000     0.00     0.00  ExecProject





regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Sharing more infrastructure between walsenders and regular backends (was Re: Switching timeline over streaming replication)
Next
From: "Albe Laurenz"
Date:
Subject: Re: Missing OID define