Re: pg_plan_advice - Mailing list pgsql-hackers

From John Naylor
Subject Re: pg_plan_advice
Date
Msg-id CANWCAZZgKnf8dNOd_w03n88NqOfmMnMv2=D8_Oy6ADGyiMq+cg@mail.gmail.com
Whole thread Raw
In response to Re: pg_plan_advice  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pg_plan_advice
List pgsql-hackers
On Tue, Jan 13, 2026 at 12:14 AM Robert Haas <robertmhaas@gmail.com> wrote:
> Here's v9. Changes:

This is perhaps the least interesting part of 0005, but since I
committed this API, I thought I'd chime in:

+ /* alias_name may not be NULL */
+ sp_len = fasthash_accum_cstring(&hs, key.alias_name);
+
+ /* partition_name and plan_name, however, can be NULL */
+ if (key.partition_name != NULL)
+ sp_len += fasthash_accum_cstring(&hs, key.partition_name);
+ if (key.plan_name != NULL)
+ sp_len += fasthash_accum_cstring(&hs, key.plan_name);

It looks like it would be helpful if fasthash_accum_cstring just
returned zero when given a NULL string, as in the attached. We could
also do something like add a large number to the hash, but I'm not
sure that's necessary.

+ /*
+ * hashfn_unstable.h recommends using string length as tweak. It's not
+ * clear to me what to do if there are multiple strings, so for now I'm
+ * just using the total of all of the lengths.
+ */
+ return fasthash_final32(&hs, sp_len);

Sounds reasonable, so the patch also documents that.

--
John Naylor
Amazon Web Services

Attachment

pgsql-hackers by date:

Previous
From: Álvaro Herrera
Date:
Subject: Re: [PATCH} Move instrumentation structs
Next
From: John Naylor
Date:
Subject: Re: [PATCH} Move instrumentation structs