RE: Parallel INSERT (INTO ... SELECT ...)

Поиск
Список
Период
Сортировка
От tsunakawa.takay@fujitsu.com
Тема RE: Parallel INSERT (INTO ... SELECT ...)
Дата
Msg-id TYAPR01MB2990212C1E8FD175957E2881FE8D9@TYAPR01MB2990.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на RE: Parallel INSERT (INTO ... SELECT ...)  ("Hou, Zhijie" <houzj.fnst@cn.fujitsu.com>)
Ответы RE: Parallel INSERT (INTO ... SELECT ...)  ("Hou, Zhijie" <houzj.fnst@cn.fujitsu.com>)
Список 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 по дате отправления:

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: TRUNCATE on foreign table
Следующее
От: "Hou, Zhijie"
Дата:
Сообщение: RE: Parallel INSERT (INTO ... SELECT ...)