Re: update on TOAST status'

tOM lANE wrote:
> JanWieck(at)t-online(dot)de (Jan Wieck) writes:
> > Tom Lane wrote:
> >> One answer is to rebuild indexes from scratch during VACUUM,
> >> before we vacuum the TOAST relation. We've been talking about
> >> doing that for a long time. Maybe it's time to bite the bullet
> >> and do it. (Of course that means fixing the relation-versioning
> >> problem, which it seems we don't have a consensus on yet...)
>
> > Doesn't matter if we do it before or after, because the main
> > heap shouldn't contain any more toast references to deleted
> > (later to be vacuumed) toast entries at that time.
>
> No, we must fix the indexes first, so that they contain no bogus
> values if we fail while vacuuming the TOAST relation.

Got me.

> > Anyway, it's a nice idea that should solve the problem. For
> > indices, which can allways be rebuilt from the heap data, I
> > don't see such a big need for the versioning. Only that a
> > partially rebuilt index (rebuild crashed in the middle) needs
> > another vacuum before the the DB is accessible again. How
> > often does that happen?
>
> If it happens just once on one of your system-table indices, you
> won't be happy. We've sweated hard to make VACUUM crash-safe,
> and I don't want to throw that away because of TOAST.

Alternatively we could go for both methods. Does any system
catalog have an index on a varlena field? If not, we could do
the classic vacuum on anything that is either a catalog or a
table that doesn't have a toast relation. Then do the lazy
reindex from scratch on anything left.

>
> >> Text *is* marked toastable in current CVS...
>
> > Whow - haven't noticed.
>
> > Will run my tests against text ... parallel. Does it have any
> > impact on the regression test execution time? Does any toast
> > table (that should now be there in the regression DB) loose
> > it's zero size during the tests?
>
> Yes, there are some nonzero-size toast files in there. Haven't
> tried to run any timing tests...

No, there aren't. All you've seen are their indices of 16K
each. But my tests, formerly using lztext, ran smooth with
text.

I've looked at textout() and, well, your style of detoasting
arguments looks alot better and easier. From the way it's
implemented I assume the per tuple memory context is done
too, no?

Jan

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #