Re: Inefficiency in InitIndexFreeSpaceMap

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Inefficiency in InitIndexFreeSpaceMap
Дата
Msg-id 17055.1225979952@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Inefficiency in InitIndexFreeSpaceMap  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Tom Lane wrote:
>> Why is InitIndexFreeSpaceMap coded to test for the FSM file already
>> existing?  AFAICS it cannot yet exist and it should be an error anyway
>> if it does.

> Hmm. The FSM file can exist, if the index isn't created anew, but 
> truncated and rebuilt. However, we normally create a new relfilenode in 
> that case, so the only place where that actually happens is with a 
> temporary ON COMMIT DELETE ROWS table.

Hm.  I would say that the brokenness in RelationTruncateIndexes is that
it truncates the main fork and not the others.  This is unlike other
places that do such things.

>> The smgrexists probe is hardly free, so losing it would be
>> good.

> Well, it's only done in index build, so I'm not too worried.

See Kevin Grittner's gripe about the speed of temp table creation.
I'm already worried that the FSM changes will have a huge negative
impact on that.  Adding extra filesystem operations that don't have
to be there doesn't help.
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [WIP] In-place upgrade
Следующее
От: Simon Riggs
Дата:
Сообщение: Timing problem in DROP TABLESPACE?