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 <and...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
