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
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. |
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 |