Re: Free space mapping (was Re: Multi-Versions and Vacuum)
От | Mark Kirkwood |
---|---|
Тема | Re: Free space mapping (was Re: Multi-Versions and Vacuum) |
Дата | |
Msg-id | 3D6DE8E0.2090002@slingshot.co.nz обсуждение исходный текст |
Ответ на | Re: Free space mapping (was Re: Multi-Versions and Vacuum) (Mark Kirkwood <markir@slingshot.co.nz>) |
Ответы |
Re: Free space mapping (was Re: Multi-Versions and Vacuum)
Re: Free space mapping (was Re: Multi-Versions and Vacuum) |
Список | pgsql-general |
Tom Lane wrote: >It doesn't need a lot of examination in my mind: the cause is surely >growth of the index on the toast table. > > You are indeed correct ! A quick check of my test case shows that the toast table growth tails off ( provided max_fsm_pages is suitably set), and the unbounded growth comes entirely from the toast index. Applying REINDEX brings the space usage down to a level that compares with a non-toasted example. With respect to the REINDEX workaround - having to re-start your server single process for it is a bit fatal if you are 24/7 shop - I think altering those high hit tables to have attributes detoasted might be better (row length permitting). Anyway that has *toasted* the need for my currrent little investigation (quite enjoyed my romp through the code, so I am not too worried). I still have some free time (I am off work after knee operation) so I'm now looking for another project.... regards Mark
В списке pgsql-general по дате отправления: