Re: 10 missing features - Mailing list pgsql-general

-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of mark
Sent: Monday, April 25, 2011 10:30 AM
To: 'Linos'; pgsql-general@postgresql.org
Subject: Re: [GENERAL] 10 missing features



> -----Original Message-----
> From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-
> owner@postgresql.org] On Behalf Of Linos
> Sent: Monday, April 25, 2011 2:42 AM
> To: pgsql-general@postgresql.org
> Subject: [GENERAL] 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.