From: "Philip Scott" <pscott@foo.me.uk>
To: "'Claudio Freire'" <klaussfreire@gmail.com>,
	<postgresql@foo.me.uk>
Cc: "'postgres performance list'" <pgsql-performance@postgresql.org>
References: <092a01cdd230$ff6143c0$fe23cb40$@foo.me.uk>
	<CAGTBQpaKOfZs+qy+S7CCPcTg7PYOrwgcQAXgWV88cQTn-BFstg@mail.gmail.com>
In-Reply-To: 
 <CAGTBQpaKOfZs+qy+S7CCPcTg7PYOrwgcQAXgWV88cQTn-BFstg@mail.gmail.com>
Date: Tue, 4 Dec 2012 18:31:05 -0000
Message-ID: <098101cdd24d$892524c0$9b6f6e40$@foo.me.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AQE7bKfasxp9xMk0I5yxURpgMQ+bBAG7NE8VmR/nQUA=
Content-Language: en-gb
Subject: Re: Slow query: bitmap scan troubles
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

> The difference between cost estimation and actual cost of your queries,
under relatively precise row estimates, seems to suggest your e_c_s or r_p_c
aren't a reflection of your hardware's performance.

Wow, so tweaking these has fixed it and then some. It now picks a slightly
different plan than the 'fast' one previously:

New super fast version with e_c_s 6GB->88Gb and r_p_c 2-> 1 (s_p_c 1->0.5):
http://explain.depesz.com/s/ECk

For reference:
> Slow version with bitmapscan enabled: http://explain.depesz.com/s/6I7 
> Fast version with bitmapscan disabled: http://explain.depesz.com/s/4MWG


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance