RE: Parallel INSERT (INTO ... SELECT ...) - Mailing list pgsql-hackers

From tsunakawa.takay@fujitsu.com
Subject RE: Parallel INSERT (INTO ... SELECT ...)
Date
Msg-id TYAPR01MB2990212C1E8FD175957E2881FE8D9@TYAPR01MB2990.jpnprd01.prod.outlook.com
Whole thread Raw
In response to RE: Parallel INSERT (INTO ... SELECT ...)  ("Hou, Zhijie" <houzj.fnst@cn.fujitsu.com>)
Responses RE: Parallel INSERT (INTO ... SELECT ...)  ("Hou, Zhijie" <houzj.fnst@cn.fujitsu.com>)
List pgsql-hackers
From: Hou, Zhijie/侯 志杰 <houzj.fnst@cn.fujitsu.com>
> table and index's size after parallel insert
> ----------------------
> postgres=# select pg_size_pretty(pg_indexes_size('testscan_index'));
>  pg_size_pretty
> ----------------
>  4048 kB
> (1 row)
> 
> postgres=# select pg_size_pretty(pg_relation_size('testscan_index'));
>  pg_size_pretty
> ----------------
>  4768 kB
> (1 row)

Which of the above shows the table size?  What does pg_indexes_size() against an index (testscan_index) return?


> IMO, due to the difference of inserts with parallel execution,
> the btree insert's cost is more than serial.
> 
> At the same time, the parallel does not have a huge performance gain with
> bitmapscan,
> So the extra cost of btree index will result in performance degradation.

How did you know that the parallelism didn't have a huge performance gain with bitmap scan?

[serial]
   ->  Bitmap Heap Scan on public.x  (cost=3272.20..3652841.26 rows=79918 width=8) (actual time=8.096..41.005
rows=129999loops=1)
 

[parallel]
         ->  Parallel Bitmap Heap Scan on public.x  (cost=3272.20..1260119.35 rows=19980 width=8) (actual
time=5.832..14.787rows=26000 loops=5)
 


Regards
Takayuki Tsunakawa



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: TRUNCATE on foreign table
Next
From: "Hou, Zhijie"
Date:
Subject: RE: Parallel INSERT (INTO ... SELECT ...)