On 4 April 2018 at 14:10, David Rowley <david.rowley@2ndquadrant.com> wrote:
> On 4 April 2018 at 05:44, Jesper Pedersen <jesper.pedersen@redhat.com> 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.
Just for the record, some of the benchmarks I did above also used the
attached patch for the -M prepared case.
I didn't intend the patch for PostgreSQL, but I am starting to think
that it would be useful to have something to save from having to
EXECUTE PREPAREd statements 5 times before getting a generic plan.
Doing that is starting to seem a bit fragile to me. Would be nice to
have some solution, but I've so far not thought of anything better
than the attached (incomplete) patch.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
