From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
Cc: | Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Pathify RHS unique-ification for semijoin planning |
Date: | 2025-08-13 02:27:47 |
Message-ID: | 3825370.1755052067@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> Given this, I'd prefer to stick with "unique-ify", for consistency
> with the majority usage in the codebase.
+1. (Not but what I might've been responsible for many of the
existing usages, so my opinion is perhaps counting twice here.)
> In this patch, the only instance that doesn't follow the "unique-ify"
> form is the macro IS_UNIQUEIFIED_REL, as dashes are not allowed in C
> identifiers. Maybe a better alternative is IS_RELATION_UNIQUE? Any
> suggestions?
Hm ... to my ear, "unique-ified" implies that we took some positive
action to make the path's output unique, such as running it through
a hashagg or Unique node. IS_RELATION_UNIQUE only implies that the
output is unique, so for example a scan of a primary key should
satisfy such a predicate. Not having read the patch (I do hope
to get to that), I'm not sure which connotation you have in mind.
If it's the latter, IS_RELATION_UNIQUE seems like a fine name.
If it's the former, maybe something like "RELATION_WAS_MADE_UNIQUE"?
That's not very pretty though ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2025-08-13 02:53:59 | Re: Excessive LOG messages from replication slot sync worker |
Previous Message | Richard Guo | 2025-08-13 02:17:52 | Re: Pathify RHS unique-ification for semijoin planning |