From: | "Gary Doades" <gpd(at)gpdnet(dot)co(dot)uk> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: planner/optimizer question |
Date: | 2004-04-30 06:33:11 |
Message-ID: | 40920137.13806.16F37CC5@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 29 Apr 2004 at 19:17, Tom Lane wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
> > Certainly the fact that MSSQL is essentially a single-user database makes
> > things easier for them.
>
> Our recent testing (cf the "Xeon" thread) says that the interlocking we
> do to make the world safe for multiple backends has a fairly high cost
> (at least on some hardware) compared to the rest of the work in
> scenarios where you are doing zero-I/O scans of data already in memory.
> Especially so for index scans. I'm not sure this completely explains
> the differential that Gary is complaining about, but it could be part of
> it. Is it really true that MSSQL doesn't support concurrent operations?
>
> regards, tom lane
As far as I am aware SQLSever supports concurrent operations. It
certainly creates more threads for each connection. None of my
observations of the system under load (50 ish concurrent users, 150 ish
connections) suggest that it is serializing queries.
These tests are currentl on single processor Athlon XP 2000+ systems.
Regards,
Gary.
From | Date | Subject | |
---|---|---|---|
Next Message | Gary Doades | 2004-04-30 07:01:26 | Re: planner/optimizer question |
Previous Message | Joseph Shraibman | 2004-04-30 05:57:44 | Re: Insert only tables and vacuum performance |