Re: [HACKERS] Runtime Partition Pruning - Mailing list pgsql-hackers

From David Rowley
Subject Re: [HACKERS] Runtime Partition Pruning
Date
Msg-id CAKJS1f89iTbmxb+Lav4a8Mt5QZ15iv4sqc2GDH2umJs+RbSXpA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Runtime Partition Pruning  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [PATCH] Logical decoding of TRUNCATE
Next
From: Craig Ringer
Date:
Subject: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS