-----Original Message----- From: pgsql-general-owner@xxxxxxxxxxxxxx [mailto:pgsql-general-owner@xxxxxxxxxxxxxx] On Behalf Of mark Sent: Monday, April 25, 2011 10:30 AM To: 'Linos'; pgsql-general@xxxxxxxxxxxxxx Subject: Re: 10 missing features > -----Original Message----- > From: pgsql-general-owner@xxxxxxxxxxxxxx [mailto:pgsql-general- > owner@xxxxxxxxxxxxxx] On Behalf Of Linos > Sent: Monday, April 25, 2011 2:42 AM > To: pgsql-general@xxxxxxxxxxxxxx > Subject: 10 missing features > > Hi all, > only want to link this blog post > http://blog.kimiensoftware.com/2011/04/top-10-missing-postgresql- > features , i > think he may have any good points. > I think this is flame bait for rules based / query hints stuff all over again. Did anyone else notice how most of his top then comes back to "bad plans". Either the planner is really bad all the time and I never knew it or we are way overblowing things. One or two of his points are on my list as well, but as far as a TOP 10 missing features that PG "needs" his probably aren't anywhere close to what the majority of people are in need of. >>>>>>>>>>>>>>>>>> At first glance I disagree. What I see is a desire for advanced diagnostic features that aid in making complex queries (and probably queries written by others) perform better by seeing exactly what the engine is doing and also telling the engine to behave in a certain way. PostgreSQL already implicitly recognizes the fact that some queries cannot be perfectly planned - in a reasonable amount of time - due to having too many joins (from_collapse_limit, join_collapse_limit). When you make a statement regarding a "majority of people" you need to at least implicitly define your domain. The majority of people in the world do not even know WHAT PostgreSQL is. The author of the article belongs to a sub-set of database administrators that have used Oracle heavily. I would offer that only a very small number of current PostGreSQL users have that experience set. Furthermore, the profile of the typical Oracle installation and support is likely quite different than the typical profile for PostgreSQL. What is being hinted to by the author is that for PostgreSQL to handle installations more like the typical Oracle installation it would be highly desirable to have the features mentioned. Summarizing the article from my POV: Oracle gives the DBA the ability to de-shroud the database Black-Box and take more direct control (and monitoring) compared to PostgreSQL. Top 10 percentile of Oracle DBAs find being forced to treat the PostgreSQL engine as a Black-Box undesirable. The Top 10 percentile of PostgreSQL DBAs may share the same feelings but other benefits outweigh the loss of capability. In any case the majority of DBAs in both camps likely do not find such functionality necessary enough to commit to learning those tools - even if they were present. I think there is value in de-shrouding the database engine and giving the DBA more control, if desired, but I also understand that it is not a simple undertaking. However, simply attempting to decrease the value proposition is not going to sit well with those who already do value that ability. Bad plans are going to occur, and even good plans can often be improved. It is like giving a painter a canvas and some paint but not telling them the materials they are being made out of. They can likely paint you a decent scene but could likely do much better given the proper knowledge of how their materials are working. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
