On Wed, 15 May 2019 at 08:58, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> So I think David's got the right idea that match_clause_to_partition_key
> is where to handle this, and I like the fact that his patch explicitly
> represents whether we're trying to do run-time or plan-time pruning.
> I agree it's kind of invasive, and I wonder why. Shouldn't the
> additional flag just be a field in the "context" struct, instead of
> being a separate parameter that has to be laboriously passed through
> many call levels?
Thanks for having a look. I originally stayed clear of "context"
since it looks more like how we output the pruning steps, rather than
a context as to how they should be generated. But it's true, using it
saves having to pass the extra argument around, so I made that change.
> (For myself, I'd have made it just a bool not an enum, given that
> I don't foresee a need for additional values. But that's definitely
> a matter of preference.)
I've changed to bool, mostly because it makes the patch a bit smaller.
> Also, I'm a bit confused by the fact that we seem to have a bunch
> of spare-parts patches in this thread. What combination is actually
> being proposed for commit?
I was also confused at the extra two patches Amit posted. The extra
one for the tests didn't look very valid to me, as I mentioned
yesterday.
I propose the attached for master, and I'll post something for v11 shortly.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
