is this index bloat? - Mailing list pgsql-general

From Patrick Hatcher
Subject is this index bloat?
Date
Msg-id OFBB9AD7E4.AA331175-ON88256F9C.0060B5AA-88256F9C.0062E8DA@fds.com
Whole thread Raw
Responses Re: is this index bloat?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general



PG=7.4.5

I guess I never noticed this during vacuum verbose before, but is it common
for the index to be 2 to 3 times the number of rows in a table?  I've tried
reindexing and then dropping and readding them.  Still the same number of
rows.
Indexes are all btree

mdc_oz=# select count(*) from kst;
 count
-------
   919
(1 row)

mdc_oz=# vacuum full verbose analyze  kst;
INFO:  vacuuming "public.kst"
INFO:  "kst": found 0 removable, 2757 nonremovable row versions in 64 pages
DETAIL:  1838 dead row versions cannot be removed yet.
Nonremovable row versions range from 141 to 235 bytes long.
There were 0 unused item pointers.
Total free space (including removable row versions) is 9112 bytes.
0 pages are or will become empty, including 0 at the end of the table.
8 pages containing 5328 free bytes are potential move destinations.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  index "xie1kst" now contains 2757 row versions in 9 pages
DETAIL:  0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  index "xie2kst" now contains 2757 row versions in 9 pages
DETAIL:  0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  index "kst_dpt_pk" now contains 2757 row versions in 9 pages
DETAIL:  0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  "kst": moved 0 row versions, truncated 64 to 64 pages
DETAIL:  CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  analyzing "public.kst"
INFO:  "kst": 64 pages, 919 rows sampled, 919 estimated total rows
VACUUM


# - Free Space Map -

max_fsm_pages = 3000000         # min max_fsm_relations*16, 6 bytes each
max_fsm_relations = 500         # min 100, ~50 bytes each

TIA


Patrick Hatcher


pgsql-general by date:

Previous
From: elein@varlena.com (elein)
Date:
Subject: plpython.so
Next
From: Tom Lane
Date:
Subject: Re: capturing/viewing sort_mem utilization on a per query basis