Re: 10 missing features

> -----Original Message-----
> From: pgsql-general-owner(at)postgresql(dot)org [mailto:pgsql-general-
> owner(at)postgresql(dot)org] On Behalf Of Greg Smith
> Sent: Monday, April 25, 2011 4:23 PM
> To: pgsql-general(at)postgresql(dot)org
> Subject: Re: [GENERAL] 10 missing features
>
> On 04/25/2011 10:48 AM, Andrew Sullivan wrote:
> > You can see this in certain items in the top 10. Three, four, five,
> > seven, maybe 8 eight, and ten all seemed to me to be things I've
> > actually done before, but not using something directly inside
> > Postgres.
> >
>
> The idea that something must ship in the database to be useful is
> really
> engrained in some people. I do this talk nowadays about common
> mistakes
> people make when deploying PostgreSQL, and one of the top items I put
> on
> there is not actively investigating external tools.

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.

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.

> None of the items on this list would be on my own top list of missing
> things in PostgreSQL. I see "Better fragmentation management" as a
> footnote and there's an intro discussion to that on the blog at
> http://blog.kimiensoftware.com/2011/04/compacting-postgresql-tables/
> Apparently the struggles required to sort out a little 25GB table
> apparently didn't make enough of an impression to put that into its
> proper place, which is way ahead of every item listed on the suggested
> missing feature set. Query progress is #1? It's annoying, yes, but so
> not even close to pole position to me. From reading the blog a bit, it
> sounds like the author is managing lots of smallish (to me) databases,
> so putting so much emphasis on making each individual one easier to
> troubleshoot makes more sense.

I think you touch on this here - but a lot of what the "most needed" things are will depend on your problem set. Lack of differential backups used to be a huge pain when I had multi-terabyte datawarehouses to look after. Ditto for query progress when I had managers asking me when ad-hoc OLAP style queries would complete.

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).

I do realize that there are ways to get at some of this stuff or work around it - but the barrier of entry is often pretty high, can involves high volume logging and is often far more time consuming task than it could be.

Brad.