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

Re: Query Performance SQL Server vs. Postgresql

From: Humair Mohammed <humairm(at)hotmail(dot)com>
To: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Query Performance SQL Server vs. Postgresql
Date: 2010-11-23 00:12:30
Message-ID: COL115-W65B2FE2559E1E7ACCDB64EA83E0@phx.gbl (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
I did some further analysis and here are the results:
work_mem;response_time1MB;62 seconds2MB;2 seconds4MB;700 milliseconds8MB;550 milliseconds
In all cases shared_buffers were set to the default value of 32MB. As you can see the 1 to 2 MB jump on the work_mem does wonders. I probably don't need this to be any higher than 8 or 16 MB. Thanks to all for help!
> Date: Mon, 22 Nov 2010 12:00:15 +0100
> Subject: Re: [PERFORM] Query Performance SQL Server vs. Postgresql
> From: tv(at)fuzzy(dot)cz
> To: humairm(at)hotmail(dot)com
> CC: pgsql-performance(at)postgresql(dot)org
> >
> >
> > Correct, the optimizer did not take the settings with the pg_ctl reload
> > command. I did a pg_ctl restart and work_mem now displays the updated
> > value. I had to bump up all the way to 2047 MB to get the response below
> > (with work_mem at 1024 MB I see 7 seconds response time) and with 2047 MB
> > (which is the max value that can be set for work_mem - anything more than
> > that results in a FATAL error because of the limit) the results are below.
> Hm, can you post explain plan for the case work_mem=1024MB. I guess the
> difference is due to caching. According to the explain analyze, there are
> just cache hits, no reads.
> Anyway the hash join uses only about 40MB of memory, so 1024MB should be
> perfectly fine and the explain plan should be exactly the same as with
> work_mem=2047MB. And the row estimates seem quite precise, so I don't
> think there's some severe overestimation.
> Tomas

In response to


pgsql-performance by date

Next:From: Merlin MoncureDate: 2010-11-23 14:20:05
Subject: Re: Query Performance SQL Server vs. Postgresql
Previous:From: Kevin GrittnerDate: 2010-11-22 17:47:15
Subject: Re: Performance under contention

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