On 6/23/06, Tom Lane <[EMAIL PROTECTED]> wrote:
What I see in this discussion is a huge amount of "the grass must be greener on the other side" syndrome, and hardly any recognition that every technique has its downsides and complications.
I'm being totally objective. I don't think we should abandon PostgreSQL's overall design at all, because we do perform INSERTs and DELETEs much better than most systems. However, I've looked at many systems and how they implement UPDATE so that it is a scalable operation. Sure, there are costs and benefits to each implementation, but I think we have some pretty brilliant people in this community and can come up with an elegant design for scalable UPDATEs.
Furthermore, I do not believe that this project has the ability to support multiple fundamental storage models, as a number of people seem to be blithely suggesting.
The fundamental storage model was not designed to be scalable. Many improvements have been done to get it where it is today. The improvements are certainly good but the model itself it isn't perfect and sometimes things need to be redesigned a bit every now and again. To be clear though, I'm in no way suggesting that we trash and rewrite PostgreSQL's storage architecture.
we can certainly make it much better than it is now, without risking killing the project by introducing undebuggable, unmaintainable complexity.
I'm not saying we rewrite the entire system in C++ (as Firebird did)... that was a risky and possibly project-killing move. I see us changing the way a single operation works through community-oriented planning and design. This approach seems to have worked for years... and includes the MVCC implementation itself. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | [EMAIL PROTECTED] Iselin, New Jersey 08830 | http://www.enterprisedb.com/ ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
