On 2023-07-02 Su 18:13, Andres Freund wrote:
Hi,
On 2023-07-02 17:57:03 -0400, Tom Lane wrote:
Andres Freund <andres@anarazel.de> writes:
Isn't that going to break the assumption that the key is unique within a
transaction?
Huh? "abc" is "abc", no matter what. At least if Andrew did what
I suggested (I didn't look at the patch yet).
Yea, I think that was a brainfart after too briefly skimming the code.
Separately, will this work correctly with procedures keeping values alive
across transactions?
That might be an issue. But couldn't we make this cache just live for
the life of the process? It's unlikely to get large.
I don't have a good handle about how big it'd end up being in some of the less
common workloads. I can imagine workloads with temp tables or such churning
through a lot of default values - often the "keyed by value" approach will
save the day, but I imagine not always.
The maximum number of entries in the table is the number of pg_attribute rows with atthasmissing = true and attbyval = false. In practice I suspect that's mostly going to be fairly low.
.oO(Perhaps we need to add a boehm style GC ... No.)
Perhaps we could defer resetting the cache to when we're not inside a
procedure?
I'm kinda leaning towards Tom's suggestion to just make it session-persistent.
I kinda wonder if this isn't basically the start of a "string interning" style
infrastructure, except for more types than just strings... I've wondered about
having that quite a few times.
maybe.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
