On 2023-07-11 Tu 10:15, Andrew Dunstan wrote:
On 2023-07-10 Mo 15:51, Andres Freund wrote:
Hi,
On 2023-07-08 08:48:00 -0400, Andrew Dunstan wrote:
On 2023-07-02 Su 22:15, Andrew Dunstan wrote:
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.
It's not really bound by that, because the set of rows can change over
time. Particularly with temp tables.
How many times are people going to add a new column with a non-null default to a temp table? Usually you know the shape you want for a temp table when you create it, I should think. Even in a long-running pgbouncer session I wouldn't expect this to balloon substantially.
The thread seems to have died down a bit. Do we have a consensus on Tom's
approach?
I guess so. It's far from pretty, but nobody really has come up with something
better.
OK, I'll send a revised patch.
Here it is. The nice thing here is that the code changes are entirely confined to heaptuple.c
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
