Re: 10 missing features - Mailing list pgsql-general

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,
asthose 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
CPUand IO utilization of particular queries or sets of queries is something I find very useful in the commercial DB
spacethat I'd love to see in Postgres.  Same goes for troubleshooting locking conflicts if you aren't looking at the
systemwhen they are happening, and tracing the causes of those locks down to finer grained details (IE - am I waiting
onbuffer 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@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books