Re: Global temporary tables

On Wed, 15 Jul 2026 at 08:57, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
>
> I'll put the patch back to WoA, until I've had a chance to look at these issues.
>

It looks like I'm not going to have any time for Postgres work for at
least the first week of this commitfest, and when I do get back to it,
my focus will probably be on v19 open items, so I might just move this
patch to the next commitfest.

I did, however, do some work on it after the last commitfest, so I'm
attaching that, just as a record of where I got to. As far as I can
remember, I fixed all the outstanding issues, and I also added a few
new tests and documentation, and a new patch implementing DISCARD
GLOBAL TEMP.

The biggest change I made was refactoring the pending inserts queue
into a new cache, which eliminated a lot of code duplication. However,
I'm not happy with where that ended up -- in particular, the flushing
code feels like a fragile hack. Having convinced myself that the
contents of pg_temp_class and pg_temp_index have to be kept in memory
for the duration of the session (or at least, beyond a single
transaction, to support things like rollback of sequence
initialization), I'm now inclined to think that it would be better to
just get rid of pg_temp_class and pg_temp_index, and have SQL-callable
functions to allow users to retrieve that data, if they need it. By
contrast, I still think having pg_temp_statistic and
pg_temp_statistic_ext_data is valuable, because (a) they're likely to
contain much more data (e.g., MCV lists), (b) I think they're much
more likely to be queried by users, and (c) having them in their
current form makes the backend code that uses stats for GTTs very
simple.

Regards,
Dean