Re: Unhappy about API changes in the no-fsm-for-small-rels patch

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Unhappy about API changes in the no-fsm-for-small-rels patch
Дата
Msg-id 20190507155731.tdrtp5ipnxumg4vc@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Unhappy about API changes in the no-fsm-for-small-rels patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Unhappy about API changes in the no-fsm-for-small-rels patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On 2019-05-07 09:34:42 -0400, Tom Lane wrote:
> I'm inclined to wonder why bother with invals at all.  The odds are
> quite good that no other backend will care (which, I imagine, is the
> reasoning behind why the original patch was designed like it was).
> A table that has a lot of concurrent write activity on it is unlikely
> to stay small enough to not have a FSM for long.

But when updating the free space for the first four blocks, we're going
to either have to do an smgrexists() to check whether somebody
concurrently created the FSM, or we might not update an existing FSM. An
inval seems much better.

Greetings,

Andres Freund



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: New EXPLAIN option: ALL
Следующее
От: Andres Freund
Дата:
Сообщение: Re: REINDEX INDEX results in a crash for an index of pg_class since9.6