Time to scale up? - Mailing list pgsql-advocacy
From | Thomas Hallgren |
---|---|
Subject | Time to scale up? |
Date | |
Msg-id | 44C4AB14.6050408@tada.se Whole thread Raw |
Responses |
Re: Time to scale up?
Re: Time to scale up? Re: Time to scale up? |
List | pgsql-advocacy |
Dear Community, The core development team has a strong and well motivated urge to keep the PostgreSQL code base focused. They don't want it to grow much and they don't want to maintain code that is written in other languages then C. This is the way it has been for a long time and I'm in no way questioning what has been accomplished so far. Question is, is that the way to go forward? Controversial question perhaps but nevertheless worth debating. Especially given the latest discussions regarding inclusion of pl/java and pl/ruby in core. A direct consequence of todays organization is that very useful functionality is scattered in several places with a significant level of uncertainty as to what is released and stable and what is just a prototype. PostgreSQL takes a beating in database comparisons and the community must time after another correct journalists that tend to "forget" the plethora of add-on modules that exists. Another consequence is that when using PostgreSQL, you are encouraged to use stored procedure languages that can be implemented with a few lines of code and in pure C. A user would probably rather see criterion's like feature richness and standards conformant. These problems persist although a number of actors bundle PostgreSQL with various modules today. A resolution to the problem would be to allow the core team to scale up. More people are needed to support a more comprehensive set of features. So why not create specialized teams that are part of the core-development trust? Teams that specialize in replication, in Java, and in other areas where the core team feel that their knowledge and/or resources are too limited. It seems to me that the community already have people that could step right in and take on this responsibility. We could ask people from the most prominent replication solutions to merge and form a team that would maintain a well defined replication portfolio. The developers that maintain the jdbc driver + people from pl/java and pl/j could do the same for Java. There are a few more areas where this would make a lot of sense. It's all about restructuring the management of the core parts of PostgreSQL in order to make it scale resource wise. It cannot, and will not, be solved by creating yet another project on PgFoundry. I know I brought this up in 'hackers' a week ago. I got no response there. I bring it up again here partly because that was the wrong forum but also because I feel that the current way to add features to the core is less then perfect and needs to be discussed. I feel that a good resolution to my concerns is extremely important for the future success of a great database. Perhaps everything that I've said so far is self-evident and thoroughly debated already. In that case, please excuse my rambling and point me in the right direction. Kind Regards, Thomas Hallgren
pgsql-advocacy by date: