From: | "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk> |
---|---|
To: | "Nicolai Tufar" <ntufar(at)apb(dot)com(dot)tr>, <pgsql-hackers(at)postgresql(dot)org>, "PgSQL Performance ML" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Realtime VACUUM, was: performance of insert/delete/update |
Date: | 2002-11-27 15:09:59 |
Message-ID: | 03AF4E498C591348A42FC93DEA9661B8128C8C@mail.vale-housing.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
> -----Original Message-----
> From: Nicolai Tufar [mailto:ntufar(at)apb(dot)com(dot)tr]
> Sent: 27 November 2002 14:02
> To: pgsql-hackers(at)postgresql(dot)org; PgSQL Performance ML
> Subject: Re: [PERFORM] [HACKERS] Realtime VACUUM, was:
> performance of insert/delete/update
>
>
> 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 .
As inspired by the SQL Server Enterprise Manager I've just been swearing
at:
"Database Optimizer"
Regards, Dave.
From | Date | Subject | |
---|---|---|---|
Next Message | Manfred Koizar | 2002-11-27 15:11:55 | Re: nested transactions |
Previous Message | Jim Beckstrom | 2002-11-27 14:43:01 | Re: [HACKERS] Realtime VACUUM, was: performance of insert/delete/update |
From | Date | Subject | |
---|---|---|---|
Next Message | Tommi Maekitalo | 2002-11-27 15:34:04 | Re: [PERFORM] Realtime VACUUM, was: performance of insert/delete/update |
Previous Message | Thrasher | 2002-11-27 14:52:20 | Child process procedures |