Tom Lane wrote:
> Gregory Stark <stark@enterprisedb.com> writes:
>
>> ... Keep in mind you're proposing to make everything run 3% slower instead of
>> using that 3% i/o bandwidth headroom to run vacuum outside the critical path.
>>
>
> I think that's actually understating the problem. Assuming this is a
> 64-bit machine (which it had better be, if you want XID to be 64 bits...)
> then the effective increase in tuple header size is not just 12 bytes
> but 16 bytes, due to alignment padding. Greg's 3% overhead number is
> only on-target if your average row width is presently about 530 bytes.
> It could easily be a whole lot less than that, and the overhead
> proportionally higher.
>
> regards, tom lane
>
overhead is not an issue here - if i lose 10 or 15% i am totally fine as
long as i can reduce vacuum overhead to an absolute minimum.
overhead will vary with row sizes anyway - this is not the point.
the point is that you don't want to potentially vacuum a table when only
a handful of records has been changed.
many thanks,
hans
--
Cybertec Schönig & Schönig GmbH
PostgreSQL Solutions and Support
Gröhrmühlgasse 26, A-2700 Wiener Neustadt
Tel: +43/1/205 10 35 / 340
www.postgresql-support.de, www.postgresql-support.com
