Hi David,
On 01/04/2018 09:21 PM, David Rowley wrote:
On 5 January 2018 at 07:16, Jesper Pedersen <jesper.peder...@redhat.com> wrote:
Could you share your thoughts on
1) if the generic plan mechanics should know about the pruning and hence
give a lower planner cost
I think the problem here is that cached_plan_cost() is costing the
planning cost of the query too low. If this was costed higher then its
more likely the generic plan would have been chosen, instead of
generating a custom plan each time.
How well does it perform if you change cpu_operator_cost = 0.01?
It gives 38.82 for generic_cost, and 108.82 for avg_custom_cost on
master (8249 TPS). And, 38.82 for generic_cost, and 79.705 for
avg_custom_cost with v17 (7891 TPS). Non-partitioned is 11722 TPS.
I think cached_plan_cost() does need an overhaul, but I think it's not
anything that should be done as part of this patch. You've picked HASH
partitioning here just because the current master does not perform any
partition pruning for that partitioning strategy.
Well, I mainly picked HASH because that is my use-case :)
For a range based setup it gives 39.84 for generic_cost, and 89.705 for
avg_custom_cost (7862 TPS).
Best regards,
Jesper
