Re: Why not represent "never vacuumed" accurately wrtpg_class.relpages?

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Why not represent "never vacuumed" accurately wrtpg_class.relpages?
Дата
Msg-id 20190105190937.GQ2528@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: Why not represent "never vacuumed" accurately wrt pg_class.relpages?  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Greetings,

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Tue, Dec 11, 2018 at 11:47 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Andres Freund <andres@anarazel.de> writes:
> > > I don't quite get why we don't instead just represent "never vacuumed"
> > > by storing a more meaningful value in relpages?
> >
> > Mostly, not wanting to break clients that look at these fields.
> > If catalog compatibility weren't a concern, I'd seriously consider
> > replacing both of them with a float "average tuples per page" ratio.
>
> I think we should do exactly that thing.

On first blush, I tend to agree, but what I really wanted to remark here
is that I don't think we should be hand-tying ourselves as to what we
can do because we don't want to upset people who are reading the
catalogs.  We make changes to the catalogs pretty regularly and while we
get complaints here and there, by and large, users are accustomed to
them and appreciate that we don't have a lot of baggage from trying to
support old interfaces and that we're able to make as much progress year
over year as we are.

Further, we support major releases for 5 years for a reason- users have
quite a bit of time to adjust to the changes.

> And I also agree that assuming 10 pages when pg_class says 0 and 1
> page when pg_class says 1 is not particularly bright.

Agreed.

Thanks!

Stephen

Вложения

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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Sketch of a fix for that truncation data corruption issue
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Record last password change