Re: [HACKERS] mdnblocks is an amazing time sink in huge relations - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] mdnblocks is an amazing time sink in huge relations
Date
Msg-id 16557.939740257@sss.pgh.pa.us
Whole thread Raw
In response to RE: [HACKERS] mdnblocks is an amazing time sink in huge relations  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Responses RE: [HACKERS] mdnblocks is an amazing time sink in huge relations  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] win32 port on newer Cygwin snapshots (990115)
Next
From: Peter Mount
Date:
Subject: RE: [HACKERS] Features for next release