On 19/11/11 11:32, Adam Cornett wrote:
On Fri, Nov 18, 2011 at 2:56 PM, Gavin Flower
<GavinFlower@archidevsys.co.nz> wrote:
On 18/11/11 04:59, Tom Lane wrote:
Craig Ringer<ringerc@ringerc.id.au> writes:
On Nov 17, 2011 1:32 PM, "Tom Lane"<tgl@sss.pgh.pa.us> 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
