Re: HASH_FIXED_SIZE flag gets lost when attaching to existing hash table

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Aidar Imamov <a(dot)imamov(at)postgrespro(dot)ru>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: HASH_FIXED_SIZE flag gets lost when attaching to existing hash table
Date: 2025-07-25 15:02:28
Message-ID: 1922301.1753455748@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Aidar Imamov <a(dot)imamov(at)postgrespro(dot)ru> writes:
> Thank's, I agree with you.
> Attaching an edited version of the patch.

Re-reading this in the light of morning, I realized that it can be
done even more simply: let's just move isfixed to the shared struct,
rather than keep two copies. The argument for two copies of keysize
et al is that they're used in hot code paths. But element_alloc()
had better not be a hot code path for a shared hash table, so I
don't think that argument has force for isfixed.

Pushed with that adjustment. I didn't back-patch, because we've
not heard complaints about people running out of shmem on Windows.
If there is anybody running a workload where this would matter,
they might be less happy not more happy about the behavior
changing in a minor release.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hironobu SUZUKI 2025-07-25 15:26:21 [PATCH] Avoid unnecessary code execution in Instrument.c when TIMING is FALSE
Previous Message Vik Fearing 2025-07-25 14:50:12 Re: Proposal: QUALIFY clause