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

Re: Query much faster with enable_seqscan=0

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: jd(at)commandprompt(dot)com
Cc: Ogden <lists(at)darkstatic(dot)com>, Jesper Krogh <jesper(at)krogh(dot)cc>, Kenneth Marshall <ktm(at)rice(dot)edu>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Query much faster with enable_seqscan=0
Date: 2010-09-21 19:16:57
Message-ID: 4C9904A9.5080301@2ndquadrant.com (view raw or flat)
Thread:
Lists: pgsql-performance
Joshua D. Drake wrote:
> PostgreSQL's defaults are based on extremely small and some would say
> (non production) size databases. As a matter of course I always
> recommend bringing seq_page_cost and random_page_cost more in line.
>   

Also, they presume that not all of your data is going to be in memory, 
and the query optimizer needs to be careful about what it does and 
doesn't pull from disk.  If that's not the case, like here where there's 
8GB of RAM and a 7GB database, dramatic reductions to both seq_page_cost 
and random_page_cost can make sense.  Don't be afraid to think lowering 
below 1.0 is going too far--something more like 0.01 for sequential and 
0.02 for random may actually reflect reality here.

-- 
Greg Smith, 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services and Support  www.2ndQuadrant.us
Author, "PostgreSQL 9.0 High Performance"    Pre-ordering at:
https://www.packtpub.com/postgresql-9-0-high-performance/book


In response to

Responses

pgsql-performance by date

Next:From: Robert HaasDate: 2010-09-21 19:27:59
Subject: Re: GPU Accelerated Sorting
Previous:From: Joshua D. DrakeDate: 2010-09-21 19:07:11
Subject: Re: Query much faster with enable_seqscan=0

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