From: Craig Ringer <craig@postnewspapers.com.au>
To: pgsql-performance@postgresql.org
Subject: Re: Chaotically weird execution plan
Date: Wed, 24 Sep 2008 11:12:26 +0800
Message-ID: <48D9B01A.5010702@postnewspapers.com.au> (raw)
In-Reply-To: <17643.1222225270@sss.pgh.pa.us>
References: <4f8bd5c90809231753xbcdacd2xfba4d38c2eb34faf@mail.gmail.com>
<48D9943B.9060801@postnewspapers.com.au>
<17643.1222225270@sss.pgh.pa.us>
Tom Lane wrote:
> Craig Ringer <craig@postnewspapers.com.au> writes:
>> I'd already written: "If you need the test for status = 1, consider a
>> partial index" when I noticed your schema definition:
>
>>> "comments_created_by" btree (created_by) WHERE status = 1
>
>> I find it hard to guess why it's having to recheck the WHERE clause
>> given the use of a partial index that should cover that nicely.
>
> No, that's operating as designed. A bitmap scan's RECHECK condition
> is only applied when the bitmap has become lossy due to memory
> pressure. In that case we have to look at each row on each of the pages
> fingered by the index as containing possible matches ... and we'd better
> check the partial-index qual too, since maybe not all the rows on those
> pages will satisfy it. In a plain indexscan there is no lossiness
> involved and so the partial-index qual need never be rechecked.
Aah. Thanks very much for the explanation of that, the plan now makes sense.
--
Craig Ringer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: craig@postnewspapers.com.au
Subject: Re: Chaotically weird execution plan
In-Reply-To: <48D9B01A.5010702@postnewspapers.com.au>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox