Message-ID: <50C90154.8060103@dunslane.net>
Date: Wed, 12 Dec 2012 17:12:36 -0500
From: Andrew Dunstan <andrew@dunslane.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Tom Lane <tgl@redhat.com>
CC: pgsql-perform <pgsql-performance@postgresql.org>
Subject: Re: encouraging index-only scans
References: <50C8F1EC.9010801@dunslane.net> <15321.1355347953@sss.pgh.pa.us>
In-Reply-To: <15321.1355347953@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org


On 12/12/2012 04:32 PM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> A client is testing a migration from 9.1 to 9.2, and has found that a
>> large number of queries run much faster if they use index-only scans.
>> However, the only way he has found to get such a plan is by increasing
>> the seq_page_cost to insanely high levels (3.5). Is there any approved
>> way to encourage such scans that's a but less violent than this?
> Is the pg_class.relallvisible estimate for the table realistic?  They
> might need a few more VACUUM and ANALYZE cycles to get it into the
> neighborhood of reality, if not.

That was the problem - I didn't know this hadn't been done.

>
> Keep in mind also that small values of random_page_cost necessarily
> decrease the apparent advantage of index-only scans.  If you think 3.5
> is an "insanely high" setting, I wonder whether you haven't driven those
> numbers too far in the other direction to compensate for something else.

Right.

Thanks for the help.

cheers

andrew


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