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

  + It's impossible for everything to be true. +

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to