Re: Temporary tables versus wraparound... again

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Temporary tables versus wraparound... again
Дата
Msg-id CAM-w4HN-9CAv3kFTKXiEktFXdfRgPJJmiYyXH4QWECTw5k7RnA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Temporary tables versus wraparound... again  (Greg Stark <stark@mit.edu>)
Ответы Re: Temporary tables versus wraparound... again
Список pgsql-hackers
On Thu, 31 Mar 2022 at 16:05, Greg Stark <stark@mit.edu> wrote:
>
> I haven't wrapped my head around multixacts yet. It's complicated by
> this same codepath being used for truncates of regular tables that
> were created in the same transaction.

So my best idea so far is to actually special-case the temp table case
in this code path. I think that's easy enough since I have the heap
tuple I'm about to replace.

In the temp table case I would just use the value Andres proposes.

In the "truncating table in same transaction it was created" case then
I would go ahead and use the expensive GetOldestMultiXactId() which
should be ok for that case. At least I think the "much higher rate"
comment was motivated by the idea that every transaction commit (when
temp tables are being used) is more frequent than any specific user
ddl.

It's not brilliant since it seems to be embedding knowledge of the
cases where this optimization applies in a lower level function. If we
think of some other case where it could apply it wouldn't be obvious
that it will have a cost to it. But it doesn't seem too terrible to
me.

An alternative would be to simply not adjust relminmxid for non-temp
tables at all. I guess that's not too bad either since these are
non-temp tables that autovacuum will be able to do anti-wraparound
vacuums on. And I get the impression mxids don't wraparound nearly as
often as xids?

-- 
greg



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

Предыдущее
От: Greg Stark
Дата:
Сообщение: Patches with failing tests in Commitfest
Следующее
От: Matthias van de Meent
Дата:
Сообщение: Re: Restructure ALTER TABLE notes to clarify table rewrites and verification scans