On 4 April 2018 at 14:10, David Rowley <david.row...@2ndquadrant.com> wrote: > On 4 April 2018 at 05:44, Jesper Pedersen <jesper.peder...@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
0001-Add-force_generic_plan-GUC.patch
Description: Binary data
