Re: update on TOAST status'

tOM lANE wrote:
> JanWieck@t-online.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@Yahoo.com #