Jim Nasby writes:
> I've verified that the patch still applies and make check-world is clean.
Not any more :-(. Here's a v3 rebased over HEAD. No substantive
change from v2.
regards, tom lane
diff --git a/src/backend/nodes/outfuncs.c b/src/backend/nodes/outfuncs.c
inde
On 3/19/17 2:32 PM, Tom Lane wrote:
Jim Nasby writes:
Having thought about it, I share Tom's concerns. And now I'm worried
about what happens if there are multiple separate OR clauses. I guess
those would be handled by separate UNIONs?
As proposed, the patch would try to optimize by splitting
I wrote:
> Consider
> SELECT count(*)
> FROM a FULL JOIN b ON (a.id = b.id)
> WHERE (a.x = 42 OR b.y = 43);
> and suppose that a and b have mutual FK constraints guaranteeing that
> every non-null a.id value has exactly one match in b and vice versa.
Oh, that was sloppy of me. J
Jim Nasby writes:
> On 3/16/17 11:54 AM, David Steele wrote:
>> On 2/14/17 4:03 PM, Tom Lane wrote:
>>> Well, the key point is whether it's really OK to de-dup on the basis
>>> of only the CTIDs that are not eliminated in any UNION arm. I was
>>> feeling fairly good about that until I thought of
On 3/16/17 11:54 AM, David Steele wrote:
On 2/14/17 4:03 PM, Tom Lane wrote:
Jim Nasby writes:
On 2/14/17 1:18 PM, Tom Lane wrote:
One point that could use further review is whether the de-duplication
algorithm is actually correct. I'm only about 95% convinced by the
argument I wrote in plan
On 2/14/17 4:03 PM, Tom Lane wrote:
> Jim Nasby writes:
>> On 2/14/17 1:18 PM, Tom Lane wrote:
>>> One point that could use further review is whether the de-duplication
>>> algorithm is actually correct. I'm only about 95% convinced by the
>>> argument I wrote in planunionor.c's header comment.
>
