On Wed, 2005-06-01 at 11:55 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > 4. Optionally, we set a flag on the table showing the whole table is
> > frozen. Anybody writing to this table subsequently will spoil this flag.
> > If the flag is set, all forms of VACUUM will return success immediately
> > without performing a scan (since it is already in a perfect VACUUM FULL
> > and VACUUM FREEZE state).
>
> This bit strikes me as dangerous and not related to the original
> proposal. I don't care for the load-already-frozen-data part at all,
> either. That's not just giving up WAL protection, that's an outright
> MVCC semantics violation, in return for which we get ... not much.
> Certainly not any speedup in the LOAD itself.
I agree it *sounds* dangerous, but is it? If so, how? I will immediately
withdraw any idea that proves dangerous.
We're holding the table lock and will continue to do so until end of
transaction. No transaction with an earlier id will ever see the data we
load because of the lock. Later transactions will see the data only when
we commit. At that stage, all they care about is that the data is
visible...it doesn't matter that we have frigged it to look like its
been there a real long time.
We're not giving up WAL protection. The PITR case is covered. Non-PITR
cases have exactly the same transactional consistency across as crash as
they do now. Nothing is lost through this proposal.
Doing those two additional actions gives us the ability to avoid:
1. avoid writing the whole table twice because of
SetBufferCommitInfoNeedsSave
2. avoid pointless VACUUMs of very large tables
3. load the table direct to read-only media, or copy it to read-only
media at some point in the future without needing to do a VACUUM FREEZE
All of that means we write the table once, rather than 3 times over the
lifetime of the table. And we only need scan it for user SQL, not for
wrap-around avoiding VACUUMs.
I know you have a solution to the second one in mind. I would not argue
against the needs-vacuuming bitmap idea when that comes back around.
Best Regards, Simon Riggs
