Re: [HACKERS] Realtime VACUUM, was: performance of

In a similar vein, setting the way back machine to the mid 80s when I was
in the USAF and teaching the computer subsystem of the A-10 INS test
station, we had old reclaimed Sperry 1650 computers (the precursor to the
1750) that had come out of the 1960 era fire control systems on
battleships like the Missouri and what not.

When the OS went south, it would put up a message that said "System Crash
at address XXXXXXX" or something very similar.  A colonol saw that and
insisted that the folks who wrote the OS change the word crash, since in
the Air Force crash (as in plane crash) had such bad connotations.  So, it
got changed to "System Fault at address xxxxxxxxx"  For the first month or
two that happened, folks would ask what a system fault was and what to do
with it.  They new that a crash would need the machine to be power cycled
but didn't know what to do with a system fault.  Shortly after that, the
manual for the test station had a little section added to it that
basically said a system fault was a crash.  :-)

On Wed, 27 Nov 2002, Jim Beckstrom wrote:

> Just for the humor of it, as well as to confirm Nick's perspective,
> years ago on our inhouse developed Burroughs mainframe dbms, we had a
> process called "garbage collect".
>
> Nicolai Tufar wrote:
>
> >I always wandered if VACUUM is the right name for the porcess. Now, when
> >PostgreSQL
> >is actively challenging in Enterprise space, it might be a good idea to give
> >it a more
> >enterprise-like name. Try to think how it is looking for an outside person
> >to see
> >us, database professionals hold lenghty discussions about the ways we
> >vacuum a database. Why should you need to vacuum a database? Is it
> >dirty? In my personal opinion, something like "space reclaiming daemon",
> >"free-list organizer", "tuple recyle job" or "segment coalesce process"
> >would
> >sound more business-like .
> >