Re: WIP: Avoid creation of the free space map for small tables

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: WIP: Avoid creation of the free space map for small tables
Дата
Msg-id CAA4eK1LOOY9PDvA0DX50N=bFZ9=8oe_MaRGbKVO7oUYj-eVNSw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: WIP: Avoid creation of the free space map for small tables  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: WIP: Avoid creation of the free space map for small tables  (Robert Haas <robertmhaas@gmail.com>)
Re: WIP: Avoid creation of the free space map for small tables  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: WIP: Avoid creation of the free space map for small tables  (John Naylor <john.naylor@2ndquadrant.com>)
Список pgsql-hackers
On Fri, Feb 22, 2019 at 1:57 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>
> I think this test is going to break on nonstandard block sizes.  While
> we don't promise that all tests work on such installs (particularly
> planner ones),
>

The reason for not pushing much on making the test pass for
nonstandard block sizes is that when I tried existing tests, there
were already some failures.  For example, see the failures in the
attached regression diff files (for block_size as 16K and 32K
respectively).  I saw those failures during the previous
investigation, the situation on HEAD might or might not be exactly the
same.  Whereas I see the value in trying to make sure that tests pass
for nonstandard block sizes, but that doesn't seem to be followed for
all the tests.

> it seems fairly easy to cope with this one -- just use a
> record size expressed as a fraction of current_setting('block_size').
> So instead of "1024" you'd write current_setting('block_size') / 8.
> And then display the relation size in terms of pages, not bytes, so
> divide pg_relation_size by block size.
>

The idea sounds good.  John, would you like to give it a try?

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Вложения

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

Предыдущее
От: "Tsunakawa, Takayuki"
Дата:
Сообщение: RE: reloption to prevent VACUUM from truncating empty pages at theend of relation
Следующее
От: Bruce Momjian
Дата:
Сообщение: Unified security key managment