Re: [HACKERS] tables > 1 gig - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] tables > 1 gig
Date
Msg-id 4361.929634829@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] tables > 1 gig  (Bruce Momjian <maillist@candle.pha.pa.us>)
Responses Re: [HACKERS] tables > 1 gig
Re: [HACKERS] tables > 1 gig
RE: [HACKERS] tables > 1 gig
List pgsql-hackers
Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> I think what we ought to do is finish working out how to make mdtruncate
>> safe for concurrent backends, and then do it.  That's the right
>> long-term answer anyway.

> Problem is, no one knows how right now.  I liked unlinking every
> segment, but was told by Hiroshi that causes a problem with concurrent
> access and vacuum because the old backends still think it is there.

I haven't been paying much attention, but I imagine that what's really
going on here is that once vacuum has collected all the still-good
tuples at the front of the relation, it doesn't bother to go through
the remaining blocks of the relation and mark everything dead therein?
It just truncates the file after the last block that it put tuples into,
right?

If this procedure works correctly for vacuuming a simple one-segment
table, then it would seem that truncation of all the later segments to
zero length should work correctly.

You could truncate to zero length *and* then unlink the files if you
had a mind to do that, but I can see why unlink without truncate would
not work reliably.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: New TODO item
Next
From: Dmitry Samersoff
Date:
Subject: Installation procedure wishes