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 <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
