Re: WIP: cross column correlation ...
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Josh Berkus <josh@agliodbs.com>
Cc: Robert Haas <robertmhaas@gmail.com>, PostgreSQL - Hans-Jürgen Schönig <postgres@cybertec.at>, pgsql-hackers Hackers <pgsql-hackers@postgresql.org>, Boszormenyi Zoltan <zb@cybertec.at>
Date: 2011-02-25T06:33:59Z
Lists: pgsql-hackers
Josh Berkus wrote: > On 2/23/11 7:10 AM, Robert Haas wrote: > > IME, most bad query plans are caused by either incorrect > > estimates of selectivity, or wrongheaded notions about what's likely > > to be cached. If we could find a way, automated or manual, of > > providing the planner some better information about the facts of life > > in those areas, I think we'd be way better off. I'm open to ideas > > about what the best way to do that is. > > As previously discussed, I'm fine with approaches which involve > modifying database objects. These are auditable and centrally managable > and aren't devastating to upgrades. > > So thinks like the proposed "CREATE SELECTIVITY" would be OK in a way > that decorating queries would not. > > Similiarly, I would love to be able to set "cache %" on a per-relation > basis, and override the whole dubious calculation involving > random_page_cost for scans of that table. We should just fine a way of checking what percentage of a table is already in the shared buffers. That doesn't help us with the kernel cache, but it would be a good start and something that doesn't require user tuning. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +