Re: planner/optimizer question

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.

In response to

Responses

Browse pgsql-performance by date

  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