Re: [HACKERS] Runtime Partition Pruning - Mailing list pgsql-hackers

From Jesper Pedersen
Subject Re: [HACKERS] Runtime Partition Pruning
Date
Msg-id 366cf4f7-ca8d-baa1-f65b-67949b56afb1@redhat.com
Whole thread Raw
In response to Re: [HACKERS] Runtime Partition Pruning  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: [HACKERS] Runtime Partition Pruning  (Beena Emerson <memissemerson@gmail.com>)
Re: [HACKERS] Runtime Partition Pruning  (David Rowley <david.rowley@2ndquadrant.com>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: BRIN FSM vacuuming questions
Next
From: Tom Lane
Date:
Subject: Re: Optimize Arm64 crc32c implementation in Postgresql