Re: freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )
Дата
Msg-id 12037.1250275044@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )  (Jeff Davis <pgsql@j-davis.com>)
Список pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> Yes. There are two ways to do the threshold:
>   1. Constant fraction of vacuum_freeze_min_age
>   2. Extra GUC

> I lean toward #1, because it avoids an extra GUC*, and it avoids the
> awkwardness when the "lower" setting is higher than the "higher"
> setting.

I tend to agree with Josh that you do need to offer two knobs.  But
expressing the second knob as a fraction (with range 0 to 1) might be
better than an independent "min" parameter.  As you say, that'd be
useful to prevent people from setting them inconsistently.

> *: As an aside, these GUCs already have incredibly confusing names, and
> an extra variable would increase the confusion. For instance, they seem
> to use "min" and "max" interchangeably.

Some of them are in fact max's, I believe.  They are complicated :-(.
It might be worth somebody taking two steps back and seeing if we need
quite so many knobs.  I think we got here partly by not wanting to
predetermine vacuuming strategies, but it doesn't help to offer
flexibility if people can't figure out how to use it.
        regards, tom lane


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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: CommitFest 2009-07: Remaining Patches
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Wisconsin benchmark