Re: More aggressive vacuuming of temporary tables

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: More aggressive vacuuming of temporary tables
Дата
Msg-id 20200829014318.GB1529@paquier.xyz
обсуждение исходный текст
Ответ на More aggressive vacuuming of temporary tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: More aggressive vacuuming of temporary tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: Disk-based hash aggregate's cost model
Следующее
От: Andrey Lepikhov
Дата:
Сообщение: Re: Ideas about a better API for postgres_fdw remote estimates