On Wed, Dec 12, 2012 at 05:27:39PM -0500, Andrew Dunstan wrote:
>
> On 12/12/2012 05:12 PM, Andrew Dunstan wrote:
> >
> >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.
> >
>
> Actually, the table had been analysed but not vacuumed, so this
> kinda begs the question what will happen to this value on
> pg_upgrade? Will people's queries suddenly get slower until
> autovacuum kicks in on the table?
[ moved to hackers list.]
Yes, this does seem like a problem for upgrades from 9.2 to 9.3? We can
have pg_dump --binary-upgrade set these, or have ANALYZE set it. I
would prefer the later.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +