(2018/01/16 6:38), Tom Lane wrote:
Robert Haas<robertmh...@gmail.com> writes:
On Mon, Jan 15, 2018 at 12:31 PM, Tom Lane<t...@sss.pgh.pa.us> wrote:
Hm. Simple is certainly good, but if there's multiple rows coming
back during an EPQ recheck then I think we have a performance problem.
You are correct ... I was wrong about that part, and said so in an
email on this thread sent about 45 minutes before yours.
I was wrong too.
However, I
still think the patch is a good fix for the immediate issue, unless
you see some problem with it. It's simple and back-patchable and does
not preclude further work anybody, including you, might want to do in
the future.
I still think so too.
I'm also still pretty unhappy with the amount of useless planning work
caused by doing GetExistingLocalJoinPath during path creation. It strikes
me that we could likely replace the entire thing with some code that just
reconstructs the join node's output tuple during EPQ using the rowmark
data for all the base relations.
The join tuple would be reconstructed without a local join execution plan?
Outer joins aren't really a problem:
we could tell which relations were replaced by nulls because the rowmark
values that bubbled up to the top went to nulls themselves.
Yeah, but we would need null-extension or projection...
However,
that's a nontrivial amount of work and probably wouldn't result in
something we cared to back-patch, especially since it's not really a bug
fix.
What do you think about a future extension to parameterized foreign paths?
Best regards,
Etsuro Fujita
