RE: Plans for solving the VACUUM problem

Поиск
Список
Период
Сортировка
От Lincoln Yeoh
Тема RE: Plans for solving the VACUUM problem
Дата
Msg-id 3.0.5.32.20010525102651.00ecccd0@192.228.128.13
обсуждение исходный текст
Ответ на Plans for solving the VACUUM problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Dave Blasby
Дата:
Сообщение: GiST index on data types that require compression
Следующее
От: Vinod Kurup
Дата:
Сообщение: plpgsql update bug?