Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: why postgresql over other RDBMS


  • From: Zoltan Boszormenyi <zb(at)cybertec(dot)at>
  • To: Harpreet Dhaliwal <harpreet(dot)dhaliwal01(at)gmail(dot)com>
  • Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Erik Jones <erik(at)myemma(dot)com>, Chris Browne <cbbrowne(at)acm(dot)org>, pgsql-general(at)postgresql(dot)org
  • Subject: Re: why postgresql over other RDBMS
  • Date: Sat, 26 May 2007 20:25:38 +0200
  • Message-id: <46587BA2(dot)70107(at)cybertec(dot)at>

Zoltan Boszormenyi írta:
If you ask me, yes. When I had to choose between MySQL 3.x and
PostgreSQL 6.5 a long ago and I was able to exclude the DB superuser
with REVOKE CONNECT from MySQL, I said "no, thanks".
I did it on purpose to prove that you can the external configuration
is better in this case.

I wanted to write "you can reenable the superuser to fix problems later,
so the external configuration is better".

And sorry for the top-posting.

And apart from fixing pg_hba.conf after you move the machine,
PostgreSQL is quite location agnostic network-wise.
You can modify the IP address[es] and FQDN of  the machine,
which is not easily doable if you use e.g. Informix where the hostname
is stored deep inside the DB and some subsystems break if it changes.

Harpreet Dhaliwal írta:
is the host base configuration methodology in postgres superior to other RDBMS.
is this something novel that postgres has come up with?

~Harpreet

On 5/26/07, * Tom Lane* <tgl(at)sss(dot)pgh(dot)pa(dot)us <mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us>> wrote:

    Stefan Kaltenbrunner < stefan(at)kaltenbrunner(dot)cc
    <mailto:stefan(at)kaltenbrunner(dot)cc>> writes:
    > Tom Lane wrote:
    >> A more interesting question is what sort of hardware you need
    for that
    >> actually to be a win, though.  Loading a few tables in parallel
    sounds
    >> like an ideal recipe for oversaturating your disk bandwidth...

    > you don't actually need that much of disk bandwidth both COPY
    and CREATE
    > INDEX are CPU bottlenecked on modern boxes and reasonable disk
    > subsystems - spreading their work over multiple cores/processes
    can give
    > big benefits.

    Hmm ... I wonder if that's true for COPY BINARY ...

                            regards, tom lane

    ---------------------------(end of
    broadcast)---------------------------
    TIP 2: Don't 'kill -9' the postmaster






--
----------------------------------
Zoltán Böszörményi
Cybertec Geschwinde & Schönig GmbH
http://www.postgresql.at/




Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group