On Fri, Nov 18, 2011 at 2:56 PM, Gavin Flower <GavinFlower@xxxxxxxxxxxxxxxxx> wrote:
On 18/11/11 04:59, Tom Lane wrote:Just curious...
Craig Ringer<ringerc@xxxxxxxxxxxxx> writes:
On Nov 17, 2011 1:32 PM, "Tom Lane"<tgl@xxxxxxxxxxxxx> wrote:Sure, but if he's continually adding new rows, I don't see much point in
If it's purely an insert-only table, such as a logging table, then inWon't a VACUUM FREEZE (or autovac equivalent) be necessary eventually, to
principle you only need periodic ANALYZEs and not any VACUUMs.
handle xid wraparound?
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
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
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
