Re: Weird issue with planner choosing seq scan
| От | Sean Leach |
|---|---|
| Тема | Re: Weird issue with planner choosing seq scan |
| Дата | |
| Msg-id | DF26F4B4-FCF2-40DC-89B7-859854AC628F@wiggum.com обсуждение исходный текст |
| Ответ на | Re: Weird issue with planner choosing seq scan ("Stephen Denne" <Stephen.Denne@datamail.co.nz>) |
| Список | pgsql-performance |
On Feb 25, 2008, at 2:59 PM, Stephen Denne wrote: >> > > Please know that I'm very new at advising PostgreSQL users how they > should tune their system... I'd never have known it if you hadn't said anything > > > My understanding of your vacuum verbose output was that it was > pointing out that max_fsm_pages was currently smaller than 281727, > so therefore there was no way it could contain mappings to all the > reusable space. However I don't think it is hinting at, nor > recommending a value that you should be using. > > If you do nothing, then this number of pages with reusable space > will probably continue to grow, therefore, it probably has been > growing. > > So, for example, if your max_fsm_pages is currently only 20000, then > perhaps 20000 of the 281727 pages with reusable space are in the > free space map. The remaining 260000 pages _may_ have been generated > through 20 different processes each of which created 13000 more > pages with reusable space than the map could reference. If that was > the case, then a max_fsm_pages of 33000 might be large enough. > > Do you see what I'm getting at? > I think that you should do a vacuum full of that table once, then > monitor the number of pages in it with reusable space for a while > (over a few iterations of your regular processes). That should give > you information about how much larger your max_fsm_pages should be > than it currently is. This sounds sane to me, will do. Thanks again!
В списке pgsql-performance по дате отправления: