Re: [PoC] Reducing planning time when tables have many partitions
От | Andrey Lepikhov |
---|---|
Тема | Re: [PoC] Reducing planning time when tables have many partitions |
Дата | |
Msg-id | 690e70cd-dc00-2d44-0040-5039a269e72e@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: [PoC] Reducing planning time when tables have many partitions (Yuya Watari <watari.yuya@gmail.com>) |
Ответы |
Re: [PoC] Reducing planning time when tables have many partitions
|
Список | pgsql-hackers |
On 5/7/2023 16:57, Yuya Watari wrote: > Hello, > > On Fri, Mar 10, 2023 at 5:38 PM Yuya Watari <watari.yuya@gmail.com> wrote: >> Thank you for pointing it out. I have attached the rebased version to >> this email. > > Recent commits, such as a8c09daa8b [1], have caused conflicts and > compilation errors in these patches. I have attached the fixed version > to this email. > > The v19-0004 adds an 'em_index' field representing the index within > root->eq_members of the EquivalenceMember. This field is needed to > delete EquivalenceMembers when iterating them using the ec_members > list instead of the ec_member_indexes. > > [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=a8c09daa8bb1d741bb8b3d31a12752448eb6fb7c > Discovering quality of partition pruning at the stage of execution initialization and using your set of patches I have found some dubious results with performance degradation. Look into the test case in attachment. Here is three queries. Execution times: 1 - 8s; 2 - 30s; 3 - 131s (with your patch set). 1 - 5s; 2 - 10s; 3 - 33s (current master). Maybe it is a false alarm, but on my laptop I see this degradation at every launch. -- regards, Andrey Lepikhov Postgres Professional
Вложения
В списке pgsql-hackers по дате отправления: