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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] mdnblocks is an amazing time sink in huge relations
Date: 1999-10-12 14:57:37
Message-ID: 16557.939740257@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Mount 1999-10-12 14:57:45 RE: [HACKERS] Dead CVS directories
Previous Message Peter Mount 1999-10-12 14:56:19 RE: [HACKERS] Features for next release