On Friday May 21 2004 10:48, Ed L. wrote:
> > > 1) Do the increasing values for "UnUsed" indicate leakage?
> >
> > I'm not sure. It seems a bit odd ... could you track this over a
> > longer interval? An unused tuple slot will only take 4 bytes so it
> > might take awhile to see any real consequence.
>
> Here's a longer interval, or at least a longer sequence:
INFO: Pages 22652: Changed 2, Empty 0; Tup 284164: Vac 655, Keep 0, UnUsed 1592.
INFO: Pages 22652: Changed 1, Empty 0; Tup 284169: Vac 87, Keep 0, UnUsed 2184.
INFO: Pages 22652: Changed 1, Empty 0; Tup 284170: Vac 121, Keep 0, UnUsed 2179.
INFO: Pages 22652: Changed 1, Empty 0; Tup 284171: Vac 94, Keep 0, UnUsed 2230.
INFO: Pages 22652: Changed 1, Empty 0; Tup 284172: Vac 97, Keep 0, UnUsed 2232.
INFO: Pages 22652: Changed 1, Empty 0; Tup 284173: Vac 106, Keep 0, UnUsed 2242.
INFO: Pages 22652: Changed 0, Empty 0; Tup 284203: Vac 36, Keep 0, UnUsed 2311.
INFO: Pages 22693: Changed 82, Empty 0; Tup 284278: Vac 2355, Keep 0, UnUsed 1364.
INFO: Pages 22693: Changed 10, Empty 0; Tup 284293: Vac 882, Keep 0, UnUsed 3098.
One oddity: Even immediately after a vacuum or analyze, I notice that
pg_class.reltuples is way off for this table, reporting 919373 rows
when there are only ~284K. pg_class.relpages looks precisely correct.
This is PostgreSQL 7.3.4 on hppa2.0w-hp-hpux11.00, compiled by cc -Ae.
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
