On 6/23/06, Tom Lane <tgl@sss.pgh.pa.us> 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 | jharris@enterprisedb.com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/
