Re: [HACKERS] Runtime Partition Pruning

Поиск
Список
Период
Сортировка
От Jesper Pedersen
Тема Re: [HACKERS] Runtime Partition Pruning
Дата
Msg-id 366cf4f7-ca8d-baa1-f65b-67949b56afb1@redhat.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Runtime Partition Pruning  (David Rowley <david.rowley@2ndquadrant.com>)
Ответы Re: [HACKERS] Runtime Partition Pruning  (Beena Emerson <memissemerson@gmail.com>)
Re: [HACKERS] Runtime Partition Pruning  (David Rowley <david.rowley@2ndquadrant.com>)
Список pgsql-hackers
Hi David,

On 03/31/2018 09:52 AM, David Rowley wrote:
> I've attached a new version of the patch.  I'm now at v18 after having
> some versions of the patch that I didn't release which were based on
> various versions of Amit's faster partition pruning patch.
> 

Thank you for the updated patch set !

I have tested this together with Amit's v46 patch.

The attached case doesn't trigger a generic plan, so basically all time 
is spent in GetCachedPlan.

The standard table case (std.sql) gives:

  generic_cost = 8.4525
  avg_custom_cost = 13.4525
  total_custom_cost = 67.2625

whereas the 64 hash partition case (hash.sql) gives:

  generic_cost = 540.32
  avg_custom_cost = 175.9425
  total_custom_cost = 879.7125

I tested with pgbench -M prepared -f select.sql.

Also, I'm seeing a regression for check-world in 
src/test/regress/results/inherit.out

***************
*** 642,648 ****
   ---------------------+---+---+-----
    mlparted_tab_part1  | 1 | a |
    mlparted_tab_part2a | 2 | a |
!  mlparted_tab_part2b | 2 | b | xxx
    mlparted_tab_part3  | 3 | a | xxx
   (4 rows)

--- 642,648 ----
   ---------------------+---+---+-----
    mlparted_tab_part1  | 1 | a |
    mlparted_tab_part2a | 2 | a |
!  mlparted_tab_part2b | 2 | b |
    mlparted_tab_part3  | 3 | a | xxx
   (4 rows)

I'll spend some more time tomorrow.

Thanks for working on this !

Best regards,
  Jesper

Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BRIN FSM vacuuming questions
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Optimize Arm64 crc32c implementation in Postgresql