Re: More aggressive vacuuming of temporary tables

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: More aggressive vacuuming of temporary tables
Date: 2020-08-29 01:43:18
Message-ID: 20200829014318.GB1529@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Lepikhov 2020-08-29 05:38:56 Re: Ideas about a better API for postgres_fdw remote estimates
Previous Message Jeff Davis 2020-08-29 01:32:38 Re: Disk-based hash aggregate's cost model