On 04/25/2011 04:54 PM, Nicholson, Brad (Toronto, ON, CA) wrote:
The problem is that there is a lot of noise in the add-on space. There are lots of things out there that are no longer supported or partially supported. There is a fairly high barrier of entry into figuring out which tools to use, how to put them together and what you can and can't do with them.
Right. This is why I advise people to start on it as soon as possible, to make it part of the initial testing of PostgreSQL. You have to start early on figuring which of the additional packages make sense for you, because in some environments you can't easily introduce them later if they weren't part of earlier QA. I tried to work on the barrier to entry part in my book, there's a lot of specific recommendations for add-ons in there and context about what they are and aren't good for.
If (and I stress the word if) the target is winning over DBA's from the commercial crowd this is an important point, as those DBA's are going to be used to getting most of what they need in one package along with the DB.
Unfortunately that whole line of thinking is fundamentally incompatible with how open source databases are built and packaged. What some people don't seem to get is that the "one package" here is "one operating system distribution with a good package manager". It's not like you have to build all this stuff from source or anything; in many cases the packages are available to add with a quick search and a few clicks.
I do think the areas that are lacking in PG though do come to finer grain profiling of tasks. The ability to isolate CPU and IO utilization of particular queries or sets of queries is something I find very useful in the commercial DB space that I'd love to see in Postgres. Same goes for troubleshooting locking conflicts if you aren't looking at the system when they are happening, and tracing the causes of those locks down to finer grained details (IE - am I waiting on buffer eviction or xlog writes).
This is all true. Unfortunately the way I expect this areas to be addressed doesn't start with "how can PostgreSQL duplicate the Oracle solution to this problem", which is how many of these incoming requests for features start. The alternate question of "how do you provide something with the same feature set for PostgreSQL?" is the more useful one, and it doesn't lead to the same solutions. That disconnect is important to address. If people are only willing to work toward or fund solving a familiar problem, they may not recognize an alternate solution that is just as useful--just not as familiar--that is available or being built.
-- Greg Smith 2ndQuadrant US greg@xxxxxxxxxxxxxxx Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
