Re: Management tool support and scalibility

Try pgAdmin II (http://pgadmin.postgresql.org) It runs on Windows but has
plenty of features. It's main limitation is that it can only do things that
are possible via ODBC so you can't control the Postmaster or configure the
server with it (yet).

Regards, Dave.

> -----Original Message-----
> From: Kevin [mailto:TenToThe8th(at)yahoo(dot)com]
> Sent: 03 February 2002 05:25
> To: PGSQL Hackers
> Subject: [HACKERS] Management tool support and scalibility
>
>
> At my old job, we used PostgreSQL exclusively. I was doing
> programming, and it was great.
>
> At my new job I've had a chance to work with SQL Server and
> Oracle. I don't like either of them from a SQL point of
> view. They just don't compare (at least for what should be
> easy stuff, like dates). However, they did have a strong
> point where I see PostgreSQL lacking at the moment.
>
> (hint, if you read the subject, you've guessed it)
>
> E.g., Oracle 8i had a very nice management console (and from
> the glimpse of 9i I got, it's even better). You could look
> at things like database schemas via a tree view, database
> physical layouts, user information, and connection
> information. (I don't have it in front of me at the moment,
> so I'm sure there is more.) In particular I was very
> interested in the ability to view not only what query a
> connection was doing, but which operations it did that took a
> long time to process (full table scans, etc), which one it is
> working on now, and how long that one will take. I know a
> while ago someone was working on a way to get similar kinds
> of information by attaching to the backends via gdb or
> something equally dangerous/hackish/error-prone. When would
> such an ability be put into the system itself? (I believe
> Oracle does it through system tables, which I would think
> might be good for PostgreSQL, as it would be hard, and slow,
> to query each backend every time.)
>
> The other ability that Oracle had that I was impressed with
> was the ability to do partitioning. You could break a
> database up into pieces and put them on, say, different
> drives, files, whatever. This seems like a good idea, and
> one I don't believe PostgreSQL has now. I suppose if you
> wanted to put a single table on another drive, you could move
> it and symlink it, but that sounds like another dirty hack.
> The other thing it could do was take a single table and
> partition it into separate physical files based on ranges in
> a column. This could be used for archiving, for example.
>
> I know that there exist some pretty nifty third party
> solutions for distributed and/or replicated databases (as
> listed on freshmeat.net) but having a separate program
> responsible for it seems like a bad idea for maintenance.
>
> By now you are probably saying 'If you want these features,
> why don't you implement them?'. Well, I really wouldn't know
> where to begin.
> I've been on this mailing list since last July with thoughts
> of working on PostgreSQL, but more than anything it's
> convinced me that I wouldn't know where to begin. ;{ I've
> purused the source and even read a few of the interals
> documents, but I still don't think I would know what really
> needs to be done. (Not to mention that this isn't a short
> list of easy
> features.)
>
> What are all your thoughts on these items? Is PostgreSQL not
> at a point where it should be thinking of this stuff? I know
> you're adding some new features and tweaks to the engine
> still, but I think the above features would make alot of
> people more interested in PostgreSQL. Many people still
> think that open source products are just not user-friendly.
> I think these features would go a long way towards that.
>
> --Kevin
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to
> majordomo(at)postgresql(dot)org
>