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

Поиск
Список
Период
Сортировка
От John Naylor
Тема Re: WIP: Avoid creation of the free space map for small tables
Дата
Msg-id CAJVSVGWJWyM_mwh1mLWz5vfLbYhyMDqdSJ0Cp08n7EQAZ5GJvw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: WIP: Avoid creation of the free space map for small tables  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: WIP: Avoid creation of the free space map for small tables  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On 12/6/18, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Thu, Dec 6, 2018 at 10:53 PM John Naylor <jcnaylor@gmail.com> wrote:
>>
>> I've added an additional regression test for finding the right block
>> and removed a test I thought was redundant. I've kept the test file in
>> its own schedule.
>>
>
> +# ----------
> +# fsm does a vacuum, and running it in parallel seems to prevent heap
> truncation.
> +# ----------
> +test: fsm
> +
>
> It is not clear to me from the comment why running it in parallel
> prevents heap truncation, can you explain what behavior are you seeing
> and what makes you think that running it in parallel caused it?

One of the tests deletes all records from the relation and vacuums. In
serial schedule, the heap and FSM are truncated; in parallel they are
not. Make check fails, since since the tests measure relation size.
Taking a closer look, I'm even more alarmed to discover that vacuum
doesn't even seem to remove deleted rows in parallel schedule (that
was in the last test I added), which makes no sense and causes that
test to fail. I looked in vacuum.sql for possible clues, but didn't
see any. I'll have to investigate further.

-John Naylor


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

Предыдущее
От: Francesco Nidito
Дата:
Сообщение: Re: Log level of logical decoding
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock