Re: Re: [GENERAL] PostgreSQL vs. MySQL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au>
Cc: "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: Re: [GENERAL] PostgreSQL vs. MySQL
Date: 2000-07-10 02:59:28
Message-ID: 19759.963197968@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au> writes:
> I'm wondering about the comments that postgres is slower in connection
> time, could this be related to that libpq always uses asynchronous
> sockets to connect? It always turns off blocking and then goes through a
> state machine to go through the various stages of connect, instead of
> just calling connect() and waiting for the kernel to do its thing.

I think you'd be wasting your time to "improve" that. A couple of
kernel calls are not enough to explain the problem. Moreover, we
had complaints about slow startup even back when libpq had never heard
of async anything.

I believe that the problem is on the backend side: there's an awful lot
of cache-initialization and so forth that happens each time a backend
is started. It's quick enough to be hard to profile accurately,
however, so getting the info needed to speed it up is not so easy.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Philip Warner 2000-07-10 03:10:42 Re: Re: [GENERAL] PostgreSQL vs. MySQL
Previous Message Philip Warner 2000-07-10 02:24:59 Announce: Testers needed for pg_dump with BLOB support.

Browse pgsql-hackers by date

  From Date Subject
Next Message The Hermit Hacker 2000-07-10 03:03:52 [7.0.2] should this work? geo_distance() ...
Previous Message Tim Perdue 2000-07-10 02:44:06 Corruption Pt II