Re: speeding up planning with partitions

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: speeding up planning with partitions
Дата
Msg-id 72094fc9-3232-0fc7-b7cd-42e1c73d5aee@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
On 2019/03/20 11:51, Imai, Yoshikazu wrote:
> Amit-san,
> 
> On Wed, Mar 20, 2019 at 2:34 AM, Amit Langote wrote:
>> On 2019/03/20 11:21, Imai, Yoshikazu wrote:
>>> (4)
>>> We expect the performance does not depend on the number of partitions
>> after applying all patches, if possible.
>>>
>>> num of part    TPS
>>> -----------  -----
>>> 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)
>>>
>>> It seems the performance still depend on the number of partitions. At
>> the moment, I don't have any idea what cause this problem but can we improve
>> this more?
>>
>> I've noticed [1] this kind of degradation when the server is built with
>> Asserts enabled.  Did you? 
>> ...
>> [1]
>> https://www.postgresql.org/message-id/a49372b6-c044-4ac8-84ea-90ad18
>> b1770d%40lab.ntt.co.jp
> 
> No. I did test again from configuring without --enable-cassert but problem I mentioned still happens.

Hmm, OK.  Can you describe your test setup with more details?

Thanks,
Amit




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Automated way to find actual COMMIT LSN of subxact LSN
Следующее
От: "Tsunakawa, Takayuki"
Дата:
Сообщение: RE: [survey] New "Stable" QueryId based on normalized query text