From: | Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, Beena Emerson <memissemerson(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, amul sul <sulamul(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Subject: | Re: [HACKERS] Runtime Partition Pruning |
Date: | 2018-04-04 17:31:31 |
Message-ID: | 4299e229-ac29-9a47-4992-87ab9f7791d8@redhat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi David,
On 04/03/2018 10:10 PM, David Rowley wrote:
>> The attached case doesn't trigger a generic plan, so basically all time is
>> spent in GetCachedPlan.
>
> Yeah, there's still no resolution to the fact that a generic plan +
> runtime pruning might be cheaper than a custom plan. The problem is
> the generic plan appears expensive to the custom vs generic plan
> comparison due to it containing more Append subnodes and the run-time
> pruning not being taking into account by that comparison.
>
> There's been some discussion about this on this thread somewhere.
>
Forgot about that, sorry.
> I think the best solution is probably the one suggested by Robert [1]
> and that's to alter the Append plan's cost when run-time pruning is
> enabled to try to account for the run-time pruning. This would be a
> bit of a blind guess akin to what we do for clause selectivity
> estimates for Params, but it's probably better than nothing, and
> likely better than doing nothing.
>
Yeah, something based on the number of WHERE clauses, and if the
partition type has DEFAULT / NULL partition could help. Forcing
choose_custom_plan() to return false does help a lot (> 400%) for the
HASH case.
But maybe this area is best left for PG12.
> Yeah, it's a bug in v46 faster partition pruning. Discussing a fix for
> that with Amit over on [2].
>
I was running with a version of faster_part_prune_v45_fixups.patch.
Patch v49 with v18 (0001-0004) works. 0005 needs a rebase.
Thanks again,
Jesper
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2018-04-04 17:45:55 | Re: some last patches breaks plan cache |
Previous Message | Magnus Hagander | 2018-04-04 17:25:11 | Re: pgsql: Validate page level checksums in base backups |