RE: Plans for solving the VACUUM problem - Mailing list pgsql-hackers

From Lincoln Yeoh
Subject RE: Plans for solving the VACUUM problem
Date
Msg-id 3.0.5.32.20010525102651.00ecccd0@192.228.128.13
Whole thread Raw
In response to Plans for solving the VACUUM problem  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
At 10:00 AM 24-05-2001 -0700, Mikheev, Vadim wrote:
>> >> Impractical ? Oracle does it.
>> >
>> >Oracle has MVCC?
>> 
>> With restrictions, yes.
>
>What restrictions? Rollback segments size?
>Non-overwriting smgr can eat all disk space...
>
>> You didn't know that?  Vadim did ...
>
>Didn't I mention a few times that I was
>inspired by Oracle? -:)

Is there yet another way to do it, that could be better? Has Oracle
actually done it the best way for once? ;).

But as long as Postgresql doesn't get painted into a corner, it doesn't
matter so much to me - I believe you guys can do a good job (as long as
"it's ready when it's ready", not "when Marketing says so"). 

My worry is if suddenly it is better to do savepoints another way, but it
changes _usage_ and thus breaks apps. Or it makes Postgresql look really
ugly. 

Right now Postgresql is fairly neat/clean with only a few exceptions
(BLOBs, VACUUM). Whereas Oracle is full of so many cases where things were
done wrong but had to be kept that way (and erm why VARCHAR2?). And full of
bits slapped on. So I sure hope postgresql doesn't end up like Oracle.
Because if I want a Frankenstein database I'll go for Oracle. Sure it's
powerful and all that, but it's damn ugly...

Take all the time you want to do it right, coz once Postgresql gets really
popular, your hands will be even more tied. When that happens it's better
to be tied to a nice spot eh?

Cheerio,
Link.



pgsql-hackers by date:

Previous
From: Dave Blasby
Date:
Subject: GiST index on data types that require compression
Next
From: Vinod Kurup
Date:
Subject: plpgsql update bug?