Re: WIP: cross column correlation ...
От | Bruce Momjian |
---|---|
Тема | Re: WIP: cross column correlation ... |
Дата | |
Msg-id | 201102250633.p1P6Xxf08903@momjian.us обсуждение исходный текст |
Ответ на | Re: WIP: cross column correlation ... (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: WIP: cross column correlation ...
|
Список | 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. +
В списке pgsql-hackers по дате отправления: