Re: More aggressive vacuuming of temporary tables - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: More aggressive vacuuming of temporary tables
Date
Msg-id 20200829014318.GB1529@paquier.xyz
Whole thread Raw
In response to More aggressive vacuuming of temporary tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: More aggressive vacuuming of temporary tables
List pgsql-hackers
On Fri, Aug 28, 2020 at 11:46:49AM -0400, Tom Lane wrote:
> Hence I propose 0001 attached.  80% of it is just API additions to allow
> passing down the isTopLevel flag so that we can do the right thing in
> the CLUSTER case; the important change is in vacuum_set_xid_limits.
> (For ease of review, I didn't reindent the existing code in
> vacuum_set_xid_limits, but that would be something to do before commit.)

I got to wonder lately if we should not have a static state like what
we do for MyXactFlags to track down if a utility query is a top-level
one or not as most of the time we just want to check the flag as
passed down by standard_ProcessUtility().  I have faced this problem
as well lately when pushing down a PreventInTransactionBlock() for
some stuff with REINDEX for example.  Not sure how reliable this would
be though..  Passing isTopLevel down the road is a no-brainer, and
perhaps having a static value would create more problems than it
solves in practice.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Disk-based hash aggregate's cost model
Next
From: Andrey Lepikhov
Date:
Subject: Re: Ideas about a better API for postgres_fdw remote estimates