Re: New strategies for freezing, advancing relfrozenxid early
От | John Naylor |
---|---|
Тема | Re: New strategies for freezing, advancing relfrozenxid early |
Дата | |
Msg-id | CAFBsxsGf=aCRHaBuqwNnNpXbLDUkLQPnj1chCoDHKK04nAxqgw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: New strategies for freezing, advancing relfrozenxid early (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: New strategies for freezing, advancing relfrozenxid early
|
Список | pgsql-hackers |
On Thu, Jan 26, 2023 at 10:11 AM Andres Freund <andres@anarazel.de> wrote:
> I am. Just not every tradeoff. I just don't see any useful tradeoffs purely
> based on the relation size.
I expressed reservations about relation size six weeks ago:
On Wed, Dec 14, 2022 at 12:16 AM Peter Geoghegan <pg@bowt.ie> wrote:
>
> On Tue, Dec 13, 2022 at 12:29 AM John Naylor
> <john.naylor@enterprisedb.com> wrote:
> > If the number of unfrozen heap pages is the thing we care about, perhaps that, and not the total size of the table, should be the parameter that drives freezing strategy?
>
> That's not the only thing we care about, though.
That was followed by several paragraphs that never got around to explaining why table size should drive freezing strategy. Review is a feedback mechanism alerting the patch author to possible problems. Listening to feedback is like vacuum, in a way: If it hurts, you're not doing it enough.
--
John Naylor
EDB: http://www.enterprisedb.com
>
> On Tue, Dec 13, 2022 at 12:29 AM John Naylor
> <john.naylor@enterprisedb.com> wrote:
> > If the number of unfrozen heap pages is the thing we care about, perhaps that, and not the total size of the table, should be the parameter that drives freezing strategy?
>
> That's not the only thing we care about, though.
That was followed by several paragraphs that never got around to explaining why table size should drive freezing strategy. Review is a feedback mechanism alerting the patch author to possible problems. Listening to feedback is like vacuum, in a way: If it hurts, you're not doing it enough.
--
John Naylor
EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: