Re: Top five challenges - Mailing list pgsql-advocacy

On Tue, Mar 1, 2011 at 10:55 PM, Greg Sabino Mullane <greg@turnstep.com> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
>
>> 1. Easy Install
>> 2. Simple, low-overhead replication
>> 3. Upgrade-in-place
>> 4. Administration & monitoring
>> 5. Driver quality/maintenance
>
>>> ... it's really nice the number of the above issues we've knocked out
>>> since 2007.
>>
>> yes... it would be interesting to know what are the 5 next challenges :)
>
> I think we haven't finished these five yet! :)
>
>> 1. Easy Install
>
> Solved, I suppose. We've always had "yum install" and friends, and now
> we have the EDB 1-click installer. The only fly in the ointment is
> the recent crap Debian pulled (yes, what they did was correct, but
> it should have been handled much better). Hopefully that will be solved
> soon with some better (and better licensed) supporting software.
> So this one is done.
>
>> 2. Simple, low-overhead replication
>
> Great progress here with hot standby which satisfies a great number
> of replication needs with very low overhead. I would not call it
> "simple" yet, but there are some tools out there that are attempting
> to fix this. Sometimes you need more than hot standby of course, and
> none of Bucardo, Slony, or Londiste are simple or low overhead. To be
> fair, however, I wonder how simple and low overhead some of the other
> RDBMSs solutions are. This one is mostly done.
>

You're much more optimistic than I am about this. Most of the other
databases offer built in solutions that are quite a bit more flexible
than what pg offers, and I don't see any changes to that on the
horizon. See Haas' recent blog post on the topic for some limitations
we aren't trying to solve. I think we'll have to embrace statement
based replication at some point, but I know a lot of people are pretty
against the idea.

>> 3. Upgrade-in-place
>
> Big success and big fail here. pg_upgrade goes a long, long way towards
> something better than pg_dump|psql, but it's not a true upgrade-in-place,
> where I can point my Postgres X+1 at my Postgres X data directory and
> have it all work. We need to catch up with Oracle on this. Halfway done.
>

Yeah; other things like being to replicate across versions are also
something a lot of people would like to see. I think it's probably
technically doable, although again I don't see anyone interested in
working on it.

>> 4. Administration & monitoring
>
> This is a pretty vague and wide-ranging topic, so it's hard to address.
> We do have a slew of administration GUIs, and a bunch of monitoring
> tools, but especially the latter need some work. Would be nice if these
> bullet points were broken down a little further with some actual
> specific complaints or ideas. Any chance of that, Josh?
>

Yeah, I think part of the issue here is either a lack of integration
with "enterprisy" tools, or no really slick GUI of our own. (With
apologies to pgadmin, but people coming from things like oem or sql
server manager often find it very lacking)

>> 5. Driver quality/maintenance
>
> Also a little vague - which drivers? Certainly most of the major languages
> have decent drivers now. I think the Perl one is pretty good ;). PHP
> and Ruby are much improved in the last few years, and the most problematic
> one, Python, is getting better (and finally winnowing the choices as well).
>
> The maintenance is probably still an issue. Certainly there is a very
> small number of people taking care of each driver, and no single company
> (e.g. EDB) stepping up to dedicate a group of people to the care of
> feeding of a driver.
>

Yeah, I think a number of these could use someone with a more
dedicated interest in keeping them up to date with the main product
line. Also you left out ODBC, which afaik is still a bit hard for most
people to get moving with.

Robert Treat
http://www.xzilla.net