Re: AW: Coping with huge deferred-trigger lists

Tom Lane wrote:
>
> 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. 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...)

And it allows the writes that need to be done quickly to be kept
together
and the slow part to be asynchronous. I suspect that we will never be
able
to get very good statistics without separate ANALYZE so we will have
asynchronous processes anyhow.

Also, we might want to get time travel back sometime, which I guess is
still
done most effectively with current scheme + having VACUUM keeping some
history
on a per-table basis.

Other than that time travel only ;) needs recording wall-clock-time of
commits
that have modified data + some extended query features.

the (wall-clock-time,xid) table is naturally ordered by said
wall-clock-time so
it won't even need index, just a binary search access method.

------------------
Hannu