Skip site navigation (1) Skip section navigation (2)

Re: Reasons and drawbacks for unused item pointers (was: Update using primary key slow)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martin Lesser <ml-pgsql(at)bettercom(dot)de>
Cc: pgsql-performance(at)postgresql(dot)org,Denis <denis(dot)sailer(at)yellowbook(dot)com>
Subject: Re: Reasons and drawbacks for unused item pointers (was: Update using primary key slow)
Date: 2005-10-27 21:36:36
Message-ID: 24260.1130448996@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
Martin Lesser <ml-pgsql(at)bettercom(dot)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

In response to

Responses

pgsql-performance by date

Next:From: Michael BestDate: 2005-10-27 21:58:55
Subject: Re: how postgresql request the computer resources
Previous:From: Martin LesserDate: 2005-10-27 21:01:55
Subject: Re: Reasons and drawbacks for unused item pointers (was: Update using primary key slow)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group