Tom Lane wrote:
>
> Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:
> >> Perhaps instead
> >> of storing each and every trigger-related tuple in memory, we only need
> >> to store one value per affected table: the lowest CTID of any tuple
> >> that we need to revisit for deferred-trigger purposes. At the end of
> >> the transaction, scan forward from that point to the end of the table,
> >> looking for tuples that were inserted by the current xact.
>
> > I thought that this current placing of new rows at end of file is subject to
> > change soon (overwrite smgr) ?
>
> Well, the scheme would still *work* if rows were not always placed at
> the end of file, though it might get inefficient.
Even under current smgr, new rows aren't necessarily at the end.
[snip]
>
> BTW, I don't think the overwriting-smgr idea is a done deal. We haven't
> seen any design yet for exactly how it should work. Moreover, I'm
> really hesitant to throw away one of the fundamental design choices of
> Postgres: overwriting smgr is one of the things that got us to where we
> are today.
I don't think we could/should introduce an overwriting smgr
in 7.2 unless we give up current level of stablitity/
reliability. We don't have an UNDO functionality yet even
under current simple no overwrite smgr.
> Before we commit to that, we ought to do some serious study
> of the alternatives. ISTM the problem with VACUUM is not that you need
> to do a regular maintenance procedure, it's that it grabs an exclusive
> lock on the table for so long. We could live with VACUUM if it could be
> made either incremental (do a few pages and release the lock) or capable
> of running in parallel with reader & writer transactions. Vadim's
> still-not-integrated LAZY VACUUM code is an indicator that progress
> might be made in that direction. (Actually, I suppose if you look at it
> in the right way, you might think that a backgroundable VACUUM *is* an
> overwriting smgr, just an asynchronous implementation of it...)
>
The backgroundable VACUUM, reuse dead space etc .. could never
be an overwriting smgr. When a tuple is updated corresponding
index tuples must always be inserted.
regrads,
Hiroshi Inoue
