Re: Global temporary tables

On Wed, 9 Sept 2026 at 03:18, Haibo Yan <tristan(dot)yim(at)gmail(dot)com> wrote:
>
> On Wed, Sep 2, 2026 at 1:09 AM Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
> >
> > 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.
>
> I followed up on your comment in v10 that pg_temp_class and
> pg_temp_index might be better removed, with the session-local state kept
> in memory instead.
>
> I’d be interested in whether this matches the direction you had in mind
> when you mentioned removing pg_temp_class and pg_temp_index, and in
> particular whether you see any reason to keep either of those catalogs
> rather than folding this state into the existing backend-local GTT state.
>

Yes, that matches what I had in mind, and I had already made a start
on that refactoring, which gets rid of gtcatcache.c and moves the GTR
info onto the usage records. I'll finish off my refactoring, and then
post my version for comparison.

Regards,
Dean