Re: speeding up planning with partitions
От | Amit Langote |
---|---|
Тема | Re: speeding up planning with partitions |
Дата | |
Msg-id | 3b8f05d6-99ed-1c0b-687c-a01629fccce3@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | RE: speeding up planning with partitions ("Imai, Yoshikazu" <imai.yoshikazu@jp.fujitsu.com>) |
Ответы |
RE: speeding up planning with partitions
|
Список | pgsql-hackers |
Imai-san, On 2019/03/20 17:36, Imai, Yoshikazu wrote: > On Wed, Mar 20, 2019 at 8:21 AM, Amit Langote wrote: >> On 2019/03/20 12:15, Imai, Yoshikazu wrote: >>> [select1024.sql] >>> \set a random (1, 1024) >>> select * from rt where a = :a; >>> >>> [pgbench] >>> pgbench -n -f select1024.sql -T 60 >> >> Thank you. >> >> Could you please try with running pgbench for a bit longer than 60 seconds? > > I run pgbench for 180 seconds but there are still difference. Thank you very much. > 1024: 7,004 TPS > 8192: 5,859 TPS > > > I also tested for another number of partitions by running pgbench for 60 seconds. > > num of part TPS > ----------- ----- > 128 7,579 > 256 7,528 > 512 7,512 > 1024 7,257 (7274, 7246, 7252) > 2048 6,718 (6627, 6780, 6747) > 4096 6,472 (6434, 6565, 6416) (quoted from above (3)'s results) > 8192 6,008 (6018, 5999, 6007) > > > I checked whether there are the process which go through the number of partitions, but I couldn't find. I'm really wonderingwhy this degradation happens. Indeed, it's quite puzzling why. Will look into this. Thanks, Amit
В списке pgsql-hackers по дате отправления: