Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-performance by date

Next:From: Gary DoadesDate: 2004-04-30 07:01:26
Subject: Re: planner/optimizer question
Previous:From: Joseph ShraibmanDate: 2004-04-30 05:57:44
Subject: Re: Insert only tables and vacuum performance

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group