Re: [WIP] cache estimates, cache access cost
От | Robert Haas |
---|---|
Тема | Re: [WIP] cache estimates, cache access cost |
Дата | |
Msg-id | BANLkTikO-M0eBqg0AXynZ+Dq0gdNWUvcbQ@mail.gmail.com обсуждение исходный текст |
Ответ на | [WIP] cache estimates, cache access cost (Cédric Villemain <cedric.villemain.debian@gmail.com>) |
Ответы |
Re: [WIP] cache estimates, cache access cost
Re: [WIP] cache estimates, cache access cost Re: [WIP] cache estimates, cache access cost |
Список | pgsql-hackers |
On Tue, Jun 14, 2011 at 10:29 AM, Cédric Villemain <cedric.villemain.debian@gmail.com> wrote: > 0001-Add-reloscache-column-to-pg_class.patch > 0002-Add-a-function-to-update-the-new-pg_class-cols.patch > 0003-Add-ANALYZE-OSCACHE-VERBOSE-relation.patch > 0004-Add-a-Hook-to-handle-OSCache-stats.patch > 0005-Add-reloscache-to-Index-Rel-OptInfo.patch > 0006-Add-cache_page_cost-GUC.patch It seems to me that posting updated versions of this patch gets us no closer to addressing the concerns I (and Tom, on other threads) expressed about this idea previously. Specifically: 1. ANALYZE happens far too infrequently to believe that any data taken at ANALYZE time will still be relevant at execution time. 2. Using data gathered by ANALYZE will make plans less stable, and our users complain not infrequently about the plan instability we already have, therefore we should not add more. 3. Even if the data were accurate and did not cause plan stability, we have no evidence that using it will improve real-world performance. Now, it's possible that you or someone else could provide some experimental evidence refuting these points. But right now there isn't any, and until there is, -1 from me on applying any of this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: