Re: State of Beta 2
От | Tom Lane |
---|---|
Тема | Re: State of Beta 2 |
Дата | |
Msg-id | 2475.1063811527@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: State of Beta 2 (Kaare Rasmussen <kar@kakidata.dk>) |
Ответы |
Re: State of Beta 2
|
Список | pgsql-general |
Kaare Rasmussen <kar@kakidata.dk> writes: > Some people have claimed that the big commercial databases don't change their > on-disk represantation anymore. Maybe PostgreSQL could try to aim for this > goal. At the very least we could try to quantize changes --- say, allow on-disk changes only every third or fourth major release, and batch up work requiring such changes. Avoiding on-disk changes actually was a design consideration for awhile, but we sort of stopped worrying about it when the prototype version of pg_upgrade stopped working (which IIRC was because it couldn't get at what it would need to get at without being rewritten in C, and no one wanted to tackle that project). > How do other Open Source systems do ? MySQL (or maybe better: InnoDB), > FireBird ?? Dunno about MySQL. I'm pretty sure I remember Ann Harrison stating that FireBird's disk structures haven't changed since the beginning of Interbase. Which you might take as saying that they were a lot smarter than we are, but I suspect what it really means is that FireBird/Interbase hasn't undergone the kind of metamorphosis of purpose that the Postgres code base has. Keep in mind that it started as an experimental academic prototype (representing some successful ideas and some not-so-successful ones), and the current developers have been laboring to convert it into an industrial-strength production tool --- keeping the good experimental ideas, but weeding out the bad ones, and adding production-oriented features that weren't in the original design. The entire argument that version-to-version stability should be a critical goal would have been foreign to the original developers of Postgres. regards, tom lane
В списке pgsql-general по дате отправления: