Hi David,
On 01/04/2018 09:21 PM, David Rowley wrote:
> On 5 January 2018 at 07:16, Jesper Pedersen <jesper.pedersen@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
