On E, 2005-05-09 at 11:05 -0400, Christopher Browne wrote:
> Hannu Krosing wrote:

> I have added a config variable (drop_indices) to allow the use of this
> to be configured, and have added it in, with default being to use it. 

Thats great news. Will definitely start using it ASAP :)

> It is triply useful when TRUNCATE cannot be used in that:
>  1.  It means the DELETE statement doesn't need to do any work on indices
>  2.  It means the COPY statement doesn't touch the indices
>  3.  Even if there are a lot of dead tuples in the table, only the live
> ones wind up expressed in the indices that get regenerated.
> 
> There are probably some further "locality of reference" benefits in that
> all the dead tuples in 3. will be at the physical start of the table
> whereas the new, live tuples will mostly be in a somewhat sequential
> order at the physical end of the table. 
> 
> It's just too bad that we can't do a nested VACUUM (7.3 doesn't support
> that) to clean out the dead tuples at the start of this process...

VACUUM does not run inside a transaction even in ver 8.0.

It seems that latest pg versions allow nested ANALYSE.

-- 
Hannu Krosing <hannu at skype.net>