Re: New strategies for freezing, advancing relfrozenxid early

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: New strategies for freezing, advancing relfrozenxid early
Дата
Msg-id CA+TgmoaOG0mmTNNL4qxDTZ2r4BSQEjmYD9Da_eU28yAvmJ=BvQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: New strategies for freezing, advancing relfrozenxid early  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: New strategies for freezing, advancing relfrozenxid early
Список pgsql-hackers
On Thu, Jan 26, 2023 at 4:06 PM Peter Geoghegan <pg@bowt.ie> wrote:
> There is very good reason to believe that the large majority of all
> data that people store in a system like Postgres is extremely cold
> data:

The systems where I end up troubleshooting problems seem to be, most
typically, busy OLTP systems. I'm not in a position to say whether
that's more or less common than systems with extremely cold data, but
I am in a position to say that my employer will have a lot fewer happy
customers if we regress that use case. Naturally I'm keen to avoid
that.

> Having a separate aggressive step that rewrites an entire large table,
> apparently at random, is just a huge burden to users. You've said that
> you agree that it sucks, but somehow I still can't shake the feeling
> that you don't fully understand just how much it sucks.

Ha!

Well, that's possible. But maybe you don't understand how much your
patch makes other things suck.

I don't think we can really get anywhere here by postulating that the
problem is the other person's lack of understanding, even if such a
postulate should happen to be correct.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



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

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: Cygwin cleanup
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: suppressing useless wakeups in logical/worker.c