Re: encouraging index-only scans

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)redhat(dot)com>
Cc: pgsql-perform <pgsql-performance(at)postgresql(dot)org>
Subject: Re: encouraging index-only scans
Date: 2012-12-12 22:12:36
Message-ID: 50C90154.8060103@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance


On 12/12/2012 04:32 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2012-12-12 22:19:57 Re: Use gcc built-in atomic inc/dec in lock.c
Previous Message Mikko Tiihonen 2012-12-12 22:11:09 Use gcc built-in atomic inc/dec in lock.c

Browse pgsql-performance by date

  From Date Subject
Next Message Andrew Dunstan 2012-12-12 22:27:39 Re: encouraging index-only scans
Previous Message Tom Lane 2012-12-12 21:32:33 Re: encouraging index-only scans