On 19/11/11 11:32, Adam Cornett wrote:
On Fri, Nov 18, 2011 at 2:56 PM, Gavin
Flower <GavinFlower@xxxxxxxxxxxxxxxxx>
wrote:
On 18/11/11 04:59, Tom Lane wrote:
Craig Ringer<ringerc@xxxxxxxxxxxxx>
writes:
On Nov 17, 2011 1:32 PM, "Tom Lane"<tgl@xxxxxxxxxxxxx> wrote:
If it's purely an insert-only table, such as a logging
table, then in
principle you only need periodic ANALYZEs and not any
VACUUMs.
Won't a VACUUM FREEZE (or autovac equivalent) be
necessary eventually, to
handle xid wraparound?
Sure, but if he's continually adding new rows, I don't see
much point in
launching extra freeze operations.
regards, tom lane
Will the pattern of inserts be at all relevant?
For example random inserts compared to apending records. I
thought that random inserts would lead to bloat, as there
would be lots of blocks far from the optimum fill factor.
Regards,
Gavin
I might be wrong (I'm sure Tom will correct me if so), but
Postgres does not store tuples in an ordered format on disk, they
are on disk in the order they are inserted, unless the table is
re-ordered by cluster,
which only does a one time sort.
Table bloat (and the table fill factor) are usually
associated with deletes and updates. If you delete a row, or
update it so that it takes up less room (by say removing a large
text value) then postgres could use the now free space on that
page to store a new tuple.
-Adam
HI Adam,
I suspect that you are right - noiw I come to think of it- I think I
got caught out by the ghost of VSAM creeping up on me )You seriously
do NOT want to know about IBM's VSAM!).
Regards,
Gavin
|
