Re: Postgres v MySQL 5.0
| От | Dawid Kuroczko |
|---|---|
| Тема | Re: Postgres v MySQL 5.0 |
| Дата | |
| Msg-id | 758d5e7f0610220532x89e1ff4n4a765204edfce14d@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Postgres v MySQL 5.0 (Thomas Hallgren <thomas@tada.se>) |
| Ответы |
Re: Postgres v MySQL 5.0
(Josh Berkus <josh@agliodbs.com>)
|
| Список | pgsql-advocacy |
On 10/22/06, Thomas Hallgren <thomas@tada.se> wrote:
Well, problem is that we simply cannot just tell community developers
"from now on you and you will be working on graphical backup utility,
and you will be working on documenting failover". Community developers
work best at things they have confidence in and feeling of mission.
Looking at the PostgreSQL devevelopment process you will see that
PGDG often refuses half-done features on the merit that they don't
meet community standards or need more work. Some features I've
seen working, but needing more work include hierarchical queries
and on-disk bitmap indexes. And I like this approach -- what's the
use of a feature which you cannot trust, especially in database?
Of course bigger players in opensource databases may treat early
adopters as cannon fodder, but I don't think we can afford that, and
even if we could, we really should not.
And if you insist on "positioning", then well -- PostgreSQL positions
itself as most advanced open source database, giving special
attenion at data safety, standards compliance and extensibility.
Regards,
Dawid
PS: And as for outsider's perception of PostgreSQL it is still common
that people think PostgreSQL doesn't provide replication. I think Slony
really should be mentioned in "Server administration", along with
other external tools like pg_pool, or pgreplicator.
Oh, and it would be very, very good idea to put into the documentation
more verbose information how to marry PostgreSQL with external
tools. Something like a simple use cases. For instance, for "Backup
and Restore" section it would be nice to put information how to use
it together with AMANDA and with Tivoli Storage Manager. Maybe
a section about pg_pool and how can it be used to help with OLTP
load.
The problem with this suggestion is that "it does not really belong
inside the DB documentation". Hmm, then maybe it would be
a good idea to create yet another document, say "PostgreSQL 8.2
Database Administration Guide" or something like it? Distributed
together with PostgreSQL Documentation, but as a separate entry.
This would make it much easier to tell people who say that
'PostgreSQL doesn't support...' -- you should read the documentation.
What do you think?
Peter Eisentraut wrote:
> Duncan Garland wrote:
>> How do you position Postgres against MySQL 5.0?
>
> We don't. We produce useful database software, and people use it or
> they don't.
>
Positioning is all about making people consider what you do useful, no? What's useful in the
eyes of the producer is not always in alignment with the general perception of a potential
user-base. IMO, The PostgreSQL core team should be more humble to that fact. After all, you
do want your product to gain ground right? Why else are you doing this?
Well, problem is that we simply cannot just tell community developers
"from now on you and you will be working on graphical backup utility,
and you will be working on documenting failover". Community developers
work best at things they have confidence in and feeling of mission.
Looking at the PostgreSQL devevelopment process you will see that
PGDG often refuses half-done features on the merit that they don't
meet community standards or need more work. Some features I've
seen working, but needing more work include hierarchical queries
and on-disk bitmap indexes. And I like this approach -- what's the
use of a feature which you cannot trust, especially in database?
Of course bigger players in opensource databases may treat early
adopters as cannon fodder, but I don't think we can afford that, and
even if we could, we really should not.
And if you insist on "positioning", then well -- PostgreSQL positions
itself as most advanced open source database, giving special
attenion at data safety, standards compliance and extensibility.
Regards,
Dawid
PS: And as for outsider's perception of PostgreSQL it is still common
that people think PostgreSQL doesn't provide replication. I think Slony
really should be mentioned in "Server administration", along with
other external tools like pg_pool, or pgreplicator.
Oh, and it would be very, very good idea to put into the documentation
more verbose information how to marry PostgreSQL with external
tools. Something like a simple use cases. For instance, for "Backup
and Restore" section it would be nice to put information how to use
it together with AMANDA and with Tivoli Storage Manager. Maybe
a section about pg_pool and how can it be used to help with OLTP
load.
The problem with this suggestion is that "it does not really belong
inside the DB documentation". Hmm, then maybe it would be
a good idea to create yet another document, say "PostgreSQL 8.2
Database Administration Guide" or something like it? Distributed
together with PostgreSQL Documentation, but as a separate entry.
This would make it much easier to tell people who say that
'PostgreSQL doesn't support...' -- you should read the documentation.
What do you think?
В списке pgsql-advocacy по дате отправления: