Re: [HACKERS] mdnblocks is an amazing time sink in huge relations

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] mdnblocks is an amazing time sink in huge relations
Дата
Msg-id 16557.939740257@sss.pgh.pa.us
обсуждение исходный текст
Ответ на RE: [HACKERS] mdnblocks is an amazing time sink in huge relations  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Ответы RE: [HACKERS] mdnblocks is an amazing time sink in huge relations
Список pgsql-hackers
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> It's me who removed the following code from mdnblocks().
> The code caused a disaster in case of mdtruncate().
>
>                 if (v->mdfd_lstbcnt == RELSEG_SIZE
>             || .... 

OK, but do you think there's still a risk, given that we've changed
the relcache-level interlocking?

> Currently only the first segment is opened when mdopen() etc is
> called.  Would you change to check all segments at first open ?

No, I don't see a need to change that logic.  I was thinking that
since mdnblocks adds another link to the chain whenever it sees that
the current segment is exactly RELSEG_SIZE, it could just assume that
if the next-segment link is not NULL then this segment must be of
size RELSEG_SIZE and it doesn't need to check that again.  It'd only
need to do an actual check on the last chain element (plus any elements
it adds during the current call, of course).  We'd rely on the
higher-level interlock to close and reopen the virtual file when a
truncate has happened.

> If there is a relation which has multi-segment of size 0,which would
> be the last segment ?

Only the last segment can have any size other than RELSEG_SIZE, I think.
        regards, tom lane


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] win32 port on newer Cygwin snapshots (990115)
Следующее
От: Peter Mount
Дата:
Сообщение: RE: [HACKERS] Features for next release