Re: Buglist - Mailing list pgsql-general

From Vivek Khera
Subject Re: Buglist
Date
Msg-id 16194.54290.800263.142593@yertle.int.kciLink.com
Whole thread Raw
In response to Re: Buglist  ("Matthew T. O'Connor" <matthew@zeut.net>)
Responses Re: Buglist
List pgsql-general
>>>>> "MTO" == Matthew T O'Connor <matthew@zeut.net> writes:

MTO> <talking beyond my real knowledge>
MTO> Changing Postgres to perform as mentioned above is non-trivial, it would
MTO> basicially change the entire core of the system.  I think this is due to
MTO> the fact that postgres uses a non-overwriting storage manager.  This has
MTO> many benefits including MVCC, the primary disadvantage is that you need
MTO> a vacuum type process
MTO> </talking beyond my real knowledge>

I'm not promoting any change in the MVCC.  What I'm saying is that it
would be really cool if the backend process itself could recognize
that a row is no longer referenced by any transactions upon
termination of the transaction, and release it back to the system.
This is just what vacuum does but in a batched manner.  I would love
to see it incremental.  This would result in pretty much near zero
internal fragmentation, I think.

How hard that is, I have no clue.  Right now my DB is saturating the
disk and having to squeeze vacuum into a saturated disk bandwidth is
not pleasant.  Luckily, the 14-disk raid array just
arrived... hopefully that will have higher bandwidth than the 4-disk
array... ;-)



pgsql-general by date:

Previous
From: "Matthew T. O'Connor"
Date:
Subject: Re: postmaster(s) have high load average
Next
From: Lamar Owen
Date:
Subject: Re: 7.3.4 RPM