Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum
Дата
Msg-id BANLkTimTJLzdPDHrVUa=56n_mPtPtO3D3w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum
Список pgsql-hackers
On Sun, May 29, 2011 at 9:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Pavan Deolasee <pavan.deolasee@gmail.com> writes:
>> On Sun, May 29, 2011 at 8:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> That would require proof, not just suggestion.  Skipping pages will
>>> defeat the OS read-ahead algorithm, and so could easily cost more than
>>> reading them.
>
>> My worry is what we have right now is also based on just assumptions
>> and gut feelings rather than any numbers.
>
> So go collect some numbers.
>

I am sorry if I sounded terse above. But my gripe is that sometimes we
are too reluctant to listen to ideas and insist on producing some hard
numbers first which might take significant efforts. But we are not
equally strict when such changes are introduced initially. For
example, in this particular case, the change was introduced after this
discussion:

http://archives.postgresql.org/pgsql-hackers/2008-12/msg01316.php

Heikki suggested 20, Simon proposed 32 to make it a power of 2. But
why not 16 ? Thats closer to 16 than 32. And Greg yesterday said, 8 is
a better number based on his testings.

May be a performance build farm as being discussed is the solution
where we can throw some simple patches and see if something helps or
not.

Thanks,
Pavan

--
Pavan Deolasee
EnterpriseDB     http://www.enterprisedb.com


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

Предыдущее
От: Pavan Deolasee
Дата:
Сообщение: Re: Vacuum, visibility maps and SKIP_PAGES_THRESHOLD
Следующее
От: Joe Abbate
Дата:
Сообщение: Re: Getting a bug tracker for the Postgres project