(2018/08/03 5:25), Tom Lane wrote:
> What I'm thinking might be a more appropriate thing, at least for
> getting v11 out the door, is to refuse to generate partitionwise
> joins when any whole-row vars are involved.
Agreed.
> (Perhaps that's not
> enough to dodge all the problems, though?)
>
> Now, that's a bit of a problem for postgres_fdw, because it seems to
> insist on injecting WRVs even when the query text does not require any.
> Why is that, and can't we get rid of it? It's horrid for performance
> even without any of these other considerations. But if we fail to get
> rid of that in time for v11, it would mean that postgres_fdw can't
> participate in PWJ, which isn't great but I think we could live with it
> for now.
Sorry, I don't understand this. Could you elaborate on that a bit more?
> BTW, what exactly do we think the production status of PWJ is, anyway?
> I notice that upthread it was stated that enable_partitionwise_join
> defaults to off, as indeed it still does, and we'd turn it on later
> when we'd gotten rid of some memory-hogging problems. If that hasn't
> happened yet (and I don't see any open item about considering enabling
> PWJ by default for v11), then I have exactly no hesitation about
> lobotomizing PWJ as hard as we need to to mask this problem for v11.
That hasn't happened yet; I think we left that for PG12, IIRC.
Here is a patch for refusing to generate PWJ paths when WRVs are involved:
* We no longer need to handle WRVs, so I've simplified
build_joinrel_tlist() and setrefs.c to what they were before
partition-wise join went in, as in the previous patch.
* attr_needed data for each child is used for building child-joins'
tlists, but I think we can build those by applying
adjust_appendrel_attrs to the parent's tlists, without attr_needed. So,
I've also removed that as in the previous patch.
Maybe I'm missing something, though.
Best regards,
Etsuro Fujita
