Re: two queries and dual cpu (perplexed)

От: Kenneth Marshall
Тема: Re: two queries and dual cpu (perplexed)
Дата: ,
Msg-id: 20050421123623.GA9371@it.is.rice.edu
(см: обсуждение, исходный текст)
Ответ на: Re: two queries and dual cpu (perplexed)  (Jeff)
Список: pgsql-performance

Скрыть дерево обсуждения

two queries and dual cpu (perplexed)  ("Shoaib Burq (VPAC)", )
 Re: two queries and dual cpu (perplexed)  (Jeff, )
  Re: two queries and dual cpu (perplexed)  (Gavin Sherry, )
  Re: two queries and dual cpu (perplexed)  ("Shoaib Burq (VPAC)", )
   Re: two queries and dual cpu (perplexed)  (Russell Smith, )
    Re: two queries and dual cpu (perplexed)  ("Shoaib Burq (VPAC)", )
     Re: two queries and dual cpu (perplexed)  (John A Meinel, )
      Re: two queries and dual cpu (perplexed)  ("Shoaib Burq (VPAC)", )
       Re: two queries and dual cpu (perplexed)  (Gavin Sherry, )
       Re: two queries and dual cpu (perplexed)  (Jeff, )
      Re: two queries and dual cpu (perplexed)  (Tom Lane, )
       Re: two queries and dual cpu (perplexed)  ("Shoaib Burq (VPAC)", )
        Re: two queries and dual cpu (perplexed)  (John A Meinel, )
   Re: two queries and dual cpu (perplexed)  ("Shoaib Burq (VPAC)", )
  Re: two queries and dual cpu (perplexed)  ("Shoaib Burq (VPAC)", )
  Re: two queries and dual cpu (perplexed)  (Kenneth Marshall, )
 Re: two queries and dual cpu (perplexed)  (Daniel Schuchardt, )
 Re: two queries and dual cpu (perplexed)  ("Dave Held", )

On Thu, Apr 21, 2005 at 08:24:15AM -0400, Jeff wrote:
>
> On Apr 21, 2005, at 7:49 AM, Shoaib Burq (VPAC) wrote:
>
> >Now I have not touch the $PGDATA/postgresql.conf (As I know very little
> >about memory tuning) Have run VACCUM & ANALYZE.
> >
> You should really, really bump up shared_buffers and given you have 8GB
> of ram this query would likely benefit from more work_mem.
>
> >and the time taken is *twice* that for the original. The modification
> >was
> >minor. The queries do make use of both CPUs:
> >
> Is this an IO intensive query?  If running both in parellel results in
> 2x the run time and you have sufficient cpus it would (to me) indicate
> you don't have enough IO bandwidth to satisfy the query.
>

I would add to Jeff's comments, that the default configuration parameters
are fairly-to-very conservative which tends to produce plans with more I/O.
Bumping your shared_buffers, work_mem, and effective_cache_size should
allow the planner to favor plans that utilize more memory but require
less I/O. Also, with small amounts of work_mem, hash joins cannot be
used and the planner will resort to nested loops.

Ken


В списке pgsql-performance по дате сообщения:

От: Greg Stark
Дата:
Сообщение: Re: Bad n_distinct estimation; hacks suggested?
От: "Joel Fradkin"
Дата:
Сообщение: Re: Joel's Performance Issues WAS : Opteron vs Xeon