Re: Why vacuum?

On Thu, Dec 14, 2000 at 01:16:20PM +0000, Hannu Krosing wrote:
> The Hermit Hacker wrote:

<snip>

> > vadim, for v7.2, is planning on re-writing the storage manager to do
> > proper overwriting of deleted space, which will reduce the requirement for
> > vacuum to almost never ...
>
> I hope that he does it in a way that allows it to retain the old
> behaviour
> for some tables if there is need for it.

Here as well. The framework is still mostly there for multiple storage
managers: I hope Vadim takes advantage of it.

<snip>

> Time travel is/was an useful feature that is difficult to emulate
> efficiently using "other" means like rules/triggers

I've actually been doing this very thing this week. It's not _that_
horibble, but does interact really poorly with RI constraints: suddenly,
all those unique PK columns aren't so unique! This is probably the biggest
reason to do time travel in the backend. Having it on a per-table basis
would be cool.

Hmm, seems the biggest problem to doing it per table would be needing
a couple optional system attributes (e.g. tt_start and tt_stop),
and different indices, that know how to skip not-current tuples. Extra
syntax to do queries at a particular time in the past would be nice, but
not an inital requirement.

Sounds like there's something in common here with the per tuple CRC
discusson, as well as optional OID: a generic need for optional system
attributes.

Ross
--
Open source code is like a natural resource, it's the result of providing
food and sunshine to programmers, and then staying out of their way.
[...] [It] is not going away because it has utility for both the developers
and users independent of economic motivations. Jim Flynn, Sunnyvale, Calif.