From: | Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au> |
---|---|
To: | "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] backend startup |
Date: | 2000-02-10 00:44:03 |
Message-ID: | 38A209D3.D016D82D@nimrod.itg.telecom.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Don Baccus wrote:
>
> At 09:32 AM 2/10/00 +1100, Chris Bitmead wrote:
>
> >> I can see where (a) is true, but who really cares about (b) any
> >> more? NT, BSD, or Linux on a several hundred dollar PC has no problem
> >> with dozens of processes...
>
> >Well there is socket overhead and extra context-switching time.
>
> Given how expensive the basic RDBMS structure is, I imagine this
> is a bit like worrying about the fact that the bugs on my windshield
> increase drag and decrease my gas mileage.
>
> I mean ... this is undoubtably true, but really pales in comparison
> to other factors that impact my gas mileage.
Well I don't know, but I know VERSANT for example provides a lib1p.so
and a lib2p.so, and I know they make sure to link against 1p.so for
benchmarks.
> Now, if you got rid of all the baggage associated with sharing buffers,
> locking, and all the rest that goes with the multiple process model
> used by Postgres you might end up with a single-process/single client
> version that is noticably faster.
Well, I'm not talking about a single client version. That would be of
dubious value.
> But just getting rid of the kernel overhead of two processes talking
> to each other isn't going to get you much, I don't think. You might
> be able to measure it for something like "select 1", but real queries
> on real databases? I find it hard to believe.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2000-02-10 01:14:30 | Re: [HACKERS] Need confirmation of "Posix time standard" on FreeBSD |
Previous Message | Hiroshi Inoue | 2000-02-10 00:32:22 | RE: [HACKERS] TODO item |