Re: Bloated pg_shdepend_depender_index

On Fri, Mar 24, 2006 at 10:02:01AM -0500, Tom Lane wrote:
> Actually, I wonder whether VACUUM FULL shouldn't be thrown away and
> replaced by something else entirely. That algorithm only really works
> nicely when just a small percentage of the rows need to be moved to
> re-compact the table --- if you're moving lots of rows, it makes the
> index bloat situation *worse* not better because of the transient need
> for index entries pointing to both copies of moved rows. Lazy VACUUM
> has become the de-facto standard for situations where there's not a huge
> amount of empty space, and so it's not clear where the sweet spot is for
> VACUUM FULL anymore. If you've got enough disk space, a rewrite (like

Therein lies part of the problem: enough disk space. Now that we're
seeing more and more use of PostgreSQL in data warehousing, it's
becomming less safe to assume you'll have enough disk space to fix bloat
on large tables. Plus I suspect a lot of folks wouldn't be able to
tolerate being locked out of a table for that long (of course that
applies to VACUUM FULL as well...)

There's a sorta-kinda solution available for the heap, involving
repeated cycles of vacuum and then update all the tuples off the last
page, and hopefully there will be some better possibilities in 8.2. But
that still leaves indexes. Are there any improvements that can be made
in that regard? I know it's a lot harder to move index tuples around,
but surely it's not impossible (I'd hope). Or as an alternative, you
could 'move' index tuples by updating tuples in the heap and having some
means to direct what index pages the new entries should favor.

If there was some relatively easy means of compacting tables and indexes
that could operate in the background (ie: doesn't need any table-level
locks) I suspect most of the need for things like VACUUM FULL, REINDEX,
and perhaps even CLUSTER would go away.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461