From: <postgresql@foo.me.uk>
To: "'postgres performance list'" <pgsql-performance@postgresql.org>
References: <092a01cdd230$ff6143c0$fe23cb40$@foo.me.uk>
	<CAGTBQpaKOfZs+qy+S7CCPcTg7PYOrwgcQAXgWV88cQTn-BFstg@mail.gmail.com>
	<CAMkU=1wEc1cCeUdR1oZ3Q2fe2pGj6tvrwRcY2obbfEk8LcNypQ@mail.gmail.com>
	<CAGTBQpbqzBf5545-qxdLQHbLyBBOvxn3hEtjQmqEp+UJPKsSrA@mail.gmail.com>
In-Reply-To: 
 <CAGTBQpbqzBf5545-qxdLQHbLyBBOvxn3hEtjQmqEp+UJPKsSrA@mail.gmail.com>
Date: Tue, 4 Dec 2012 17:47:29 -0000
Message-ID: <096f01cdd247$722264a0$56672de0$@foo.me.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AQE7bKfasxp9xMk0I5yxURpgMQ+bBAG7NE8VAUNOjpICTD/jZpkDX2Ng
Content-Language: en-gb
Subject: Re: Slow query: bitmap scan troubles
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org


>> But the row estimates are not precise at the top of the join/filter.
>> It thinks there will 2120 rows, but there are only 11.

>Ah... I didn't spot that one...

Yes, you are right there - this is probably a slightly atypical query of
this sort actually, 2012 is a pretty good guess.

On Claudio's suggestion I have found lots more things to read up on and am
eagerly awaiting 6pm when I can bring the DB down and start tweaking. The
effective_work_mem setting is going from 6Gb->88Gb which I think will make
quite a difference.

I still can't quite wrap around my head why accessing an index is expected
to use more disk access than doing a bitmap scan of the table itself, but I
guess it does make a bit of sense if postgres assumes the table is more
likely to be cached.

It's all quite, quite fascinating :)

I'll let you know how it goes.

- Phil


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