Re: Postgres scalability and performance on windows - Mailing list pgsql-general

From Merlin Moncure
Subject Re: Postgres scalability and performance on windows
Date
Msg-id b42b73150611231910n559e733dk8a6a15184b1017a2@mail.gmail.com
Whole thread Raw
In response to Postgres scalability and performance on windows  ("Gopal" <gopal@getmapping.com>)
List pgsql-general
On 11/23/06, Gopal <gopal@getmapping.com> wrote:
> I have a postgres installation thats running under 70-80% CPU usage while
>
> an MSSQL7 installation did 'roughly' the same thing with 1-2% CPU load.

i somehow doubt ms sql server is 35x faster than postgresql in
production environments, even on windows.

> work_mem = 512                                   # min 64,
this is probably too low.

> SQL server caches all the data in memory which is making it faster(uses
> about 1.2GB memory- which is fine).
>
> But postgres has everything spread across 10-15 processes, with each process
> using about 10-30MB, not nearly enough to cache all the data and ends up
> doing a lot of disk reads.

this is a misleading and unfortuante shortcoming of the windows
process manager.  postgresql uses a lot of shared memory, and if you
have shared memory set to 10 mb, each process in the task manager can
report up to 10 mb (at the same time) even though only 10mb is really
in use.

> I've read that postgres depends on OS to cache the files, I wonder if this
> is not happenning on windows.

Are you suggesting postgresql somehow turned off file caching in windows?

> In any case I cannot believe that having 15-20 processes running on windows
> helps. Why not spwan of threads instead of processes, which might

this was an important arguement in oh, say, 1992 :-).  Seriously, even
though processes are slower in windows than threads for certain
things, it's not as much as you'd expect and certainly not causing any
performance issues you are suffering.

 My question is, should I just accept the performance I am getting as the
> limit on windows or should I be looking at some other params that I might
> have missed?

i'd start by logging queries with execution times and looking for
queries that are running the slowest.

merlin

pgsql-general by date:

Previous
From: Jerry Sievers
Date:
Subject: Re: Stuck in "DELETE waiting"
Next
From: Arnaud Lesauvage
Date:
Subject: Re: MSSQL to PostgreSQL : Encoding problem