Thread: Straight-from-the-horses-mouth dept

I've been having a lot of fun here at the SIGMOD annual conference,
attaching faces to names like Stonebraker, Hellerstein, Aoki,
Seltzer (if these do not ring a bell, you ain't read enough Postgres
source code lately).  I felt I had to pass along this gem from Joe
Hellerstein, right after he observed that he knew the PG sources
quite well, and he'd noticed MySQL was a lot smaller:

"Postgres is bloatware by design: it was built to house PhD theses."

immediately followed by

"The current maintainers [he's looking right at me while he says this]
have done a great job of trimming the fat.  I know that *my* thesis
is gone entirely."
        regards, tom lane

On Thu, 2002-06-06 at 07:18, Tom Lane wrote:
> I've been having a lot of fun here at the SIGMOD annual conference,
> attaching faces to names like Stonebraker, Hellerstein, Aoki,
> Seltzer (if these do not ring a bell, you ain't read enough Postgres
> source code lately).  I felt I had to pass along this gem from Joe
> Hellerstein, right after he observed that he knew the PG sources
> quite well, and he'd noticed MySQL was a lot smaller:
> 
> "Postgres is bloatware by design: it was built to house PhD theses."
> 
> immediately followed by
> 
> "The current maintainers [he's looking right at me while he says this]
> have done a great job of trimming the fat.  I know that *my* thesis
> is gone entirely."

I hope it is removed in such a clean way that it can be put back _as an
installable module_ if needed.

Bloatware or not, one of the main advantages of PG is that it is
designed to be extensible.

<rant>

One thing I think we have stripped too much is time travel. I hope that
there will be possibility to put back hooks for the following:

1) logging dead tuples as they are removed,either to text file or
archive table/database depending on installed logging function)

2) have VACUUM delete only tuples dead before transaction N (I'd prefer
some timestamp, but that would need logging transaction times or moving
transaction iods to 64bits so that they can embed time)

3) some way to tell postgres to get data as it was at transaction N - it
would be a great way for recovering accidentally deleted data (I send
out my quite crappy python code for retrieving dead tuples from data
files 1-2 times a month :)

SELECT * FROM MYTABLE AS OF TRANSACTION(123456) would be great.

4) some sparse logging of transaction times, say log current trx nr
every 5 minutes, making 3) more usable.

</rant>

-------------------
Hannu, anxiousy wating for more stuff the alleged horses have to say ;)

Hannu Krosing <hannu@tm.ee> writes:
> <rant>
> One thing I think we have stripped too much is time travel.

Actually, I was just discussing that at last night's dinner with someone
whose name I forget at the moment (I have his card, but not on me).
He claimed to know how to support time travel as an optional feature
--- ie, you don't pay for it if you don't need it.  I'm hoping to hear
more about this after the conference is over...
        regards, tom lane

On Thu, 2002-06-06 at 21:13, Tom Lane wrote:
> Hannu Krosing <hannu@tm.ee> writes:
> > <rant>
> > One thing I think we have stripped too much is time travel.
> 
> Actually, I was just discussing that at last night's dinner with someone
> whose name I forget at the moment (I have his card, but not on me).
> He claimed to know how to support time travel as an optional feature
> --- ie, you don't pay for it if you don't need it.  I'm hoping to hear
> more about this after the conference is over...

I guess that we could do something similar to oracle (yes, they have
some limited time travel starting from ver 9i ;-p )

1. They log transaction times at some rather coarse interval - this is
the cheap part if done relatively seldom.

2. then they have gone through much of trouble to get historic data from
the logs.

The part that could make it cheap for us is that we don't need to go to
logs, just having an option to tell the executor to assume it is in some
other transaction in some part of the tree would be enough (and to
ignore the new dead-tuple bit in indexes now that it is there) - this
should be possible at very low extra cost.

so we could resurrect old tuples by selecting them into new table:

CREATE TABLE salvage_mytable 
AS
SELECT oid as oldoid,tmin as oldtmin, ..., * FROM mytable
AS OF YESTERDAY;

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