Re: [PATCH] Keeps tracking the uniqueness with UniqueKey - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: [PATCH] Keeps tracking the uniqueness with UniqueKey
Date
Msg-id 0e4ecefb-17b2-fbe1-7c3e-e7d68a744b9b@iki.fi
Whole thread Raw
In response to Re: [PATCH] Keeps tracking the uniqueness with UniqueKey  (Andy Fan <zhihui.fan1213@gmail.com>)
Responses Re: [PATCH] Keeps tracking the uniqueness with UniqueKey  (Jesper Pedersen <jesper.pedersen@redhat.com>)
List pgsql-hackers
On 26/11/2020 16:58, Andy Fan wrote:
> This patch has stopped moving for a while,  any suggestion about
> how to move on is appreciated.

The question on whether UniqueKey.exprs should be a list of 
EquivalenceClasses or PathKeys is unresolved. I don't have an opinion on 
that, but I'd suggest that you pick one or the other and just go with 
it. If it turns out to be a bad choice, then we'll change it.

Quickly looking at the patches, there's one thing I think no one's 
mentioned yet, but looks really ugly to me:

> +        /* Make sure the path->parent point to current joinrel, can't update it in-place. */
> +        foreach(lc, outer_rel->pathlist)
> +        {
> +            Size sz = size_of_path(lfirst(lc));
> +            Path *path = palloc(sz);
> +            memcpy(path, lfirst(lc), sz);
> +            path->parent = joinrel;
> +            add_path(joinrel, path);
> +        }

Copying a Path and modifying it like that is not good, there's got to be 
a better way to do this. Perhaps wrap the original Paths in 
ProjectionPaths, where the ProjectionPath's parent is the joinrel and 
dummypp=true.

- Heikki



pgsql-hackers by date:

Previous
From: "tsunakawa.takay@fujitsu.com"
Date:
Subject: RE: POC: postgres_fdw insert batching
Next
From: Yulin PEI
Date:
Subject: 回复: [PATCH] BUG FIX: Core dump could happen when VACUUM FULL in standalone mode