Re: Reasons and drawbacks for unused item pointers (was: Update using primary key slow) - Mailing list pgsql-performance

From Tom Lane
Subject Re: Reasons and drawbacks for unused item pointers (was: Update using primary key slow)
Date
Msg-id 24260.1130448996@sss.pgh.pa.us
Whole thread Raw
In response to Re: Reasons and drawbacks for unused item pointers (was: Update using primary key slow)  (Martin Lesser <ml-pgsql@bettercom.de>)
Responses Re: Reasons and drawbacks for unused item pointers  (Martin Lesser <ml-pgsql@bettercom.de>)
List pgsql-performance
Martin Lesser <ml-pgsql@bettercom.de> writes:
> What causes this "unused item pointers" and which impact do they have
> regarding performance?

Those are item pointer slots that were once used but aren't used at the
moment.  VACUUM leaves an empty slot behind when it removes a dead
tuple, and the slot is then available for re-use next time a tuple is
created on that page.  See
http://developer.postgresql.org/docs/postgres/storage-page-layout.html

The direct performance impact is really pretty minimal (and none at all
on indexscans, AFAIR).  The reason Denis' number drew my attention was
that it implied that the table had gone un-vacuumed for awhile at some
time in the past.  His stats were showing about 64000 tuples deleted
per vacuum pass, which would have created 64000 unused item pointers
--- but in a steady-state situation those would be eaten up again by
the time of the next vacuum.  To have 1905028 unused pointers in a
table with only 5106307 live entries suggests that at some point there
were 1.9 million (or so) dead but not-yet-vacuumed tuples, which
suggests insufficient vacuuming.

            regards, tom lane

pgsql-performance by date:

Previous
From: Martin Lesser
Date:
Subject: Re: Reasons and drawbacks for unused item pointers (was: Update using primary key slow)
Next
From: Michael Best
Date:
Subject: Re: how postgresql request the computer resources