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 по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: Problem with default partition pruning
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: Offline enabling/disabling of data checksums