Horton

Re: Pathify RHS unique-ification for semijoin planning

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
Cc: Álvaro Herrera <alvherre@kurilemu.de>, Pg Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-08-13T02:27:47Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Simplify relation_has_unique_index_for()

  2. Pathify RHS unique-ification for semijoin planning

  3. Convert varatt.h access macros to static inline functions.

  4. Re-export a few of createplan.c's make_xxx() functions.

Richard Guo <guofenglinux@gmail.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