Re: New FSM patch

Поиск
Список
Период
Сортировка
От Zdenek Kotala
Тема Re: New FSM patch
Дата
Msg-id 48D2415A.3050500@sun.com
обсуждение исходный текст
Ответ на Re: New FSM patch  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: New FSM patch
Список pgsql-hackers
Heikki Linnakangas napsal(a):
> Zdenek Kotala wrote:

>> Suggestions:
>>
>> 1) remove WAL logging. I think that FSM record should be recovered 
>> during processing of others WAL records (like insert, update). 
>> Probably only we need full page write on first modification after 
>> checkpoint.
> 
> Hmm, we don't have the infrastructure to do that, but I guess it's 
> doable. In case of a crash, the FSM information after recovery wouldn't 
> obviously be up-to-date. And the FSM information in a warm standby would 
> also lag behind.
> 
> One option would be to put RecordPageWithFreeSpace() calls into 
> heap_redo, so that the FSM would be updated based on the WAL records we 
> write anyway.

Yes, it seems to be a good place.

> I think we'd still need to WAL log operations that decrease the amount 
> of free space on page. Otherwise, after we have partial vacuum, we might 
> never revisit a page, and update the FSM, even though there's usable 
> space on the page, leaving the space forgotten forever.

I think, if you update actual free space on each page which is recorded in the 
WAL then you should have actual FSM. Something like this:

RecordPageWithFreeSpace(PageGetFreeSpace(..))

<snip>

> 
> Other important test cases are various bulk insert kind of tests.

Parallel bulkload could be problem. Another problem could be CREATE TEMP TABLE 
command which updates catalog, which is usually small.
    Zdenek



-- 
Zdenek Kotala              Sun Microsystems
Prague, Czech Republic     http://sun.com/postgresql



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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: FSM patch - performance test
Следующее
От: Tom Lane
Дата:
Сообщение: Re: optimizing CleanupTempFiles