Re: benchmarking the query planner (was Re: Simple postgresql.conf wizard)
В списке pgsql-hackers по дате отправления:
| От | Robert Haas |
|---|---|
| Тема | Re: benchmarking the query planner (was Re: Simple postgresql.conf wizard) |
| Дата | |
| Msg-id | 603c8f070812080902u7aee4fc9y40d0847a737604b7@mail.gmail.com обсуждение |
| Ответ на | Re: benchmarking the query planner (was Re: Simple postgresql.conf wizard) (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
On Mon, Dec 8, 2008 at 11:56 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Greg Stark <greg.stark@enterprisedb.com> writes: >> That might only be the case when the pg_statistic record is in shared >> buffers. > > Yeah, it seems unlikely that disabling compression is a good idea in the > bigger scheme of things. Is there any way to figure out what sort of compression ratios we're typically getting? The only way compression can really be a win is if it's saving us having to read in additional pages. Even then, I'm not sure we should worry about needing to read in additional pages in this case. I would sure expect statistics to stay in shared buffers, or at least in the operating system cache. Sure, if the table is accessed VERY infrequently, that might not be the case, but is that really what we want to optimize for? ...Robert
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера