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