Re: [GENERAL] Odd VACUUM behavior when it is expected to truncate last empty pages
От | Sergey Konoplev |
---|---|
Тема | Re: [GENERAL] Odd VACUUM behavior when it is expected to truncate last empty pages |
Дата | |
Msg-id | CAL_0b1uQcZx+KScZFiE4BBj7ZHT6kgrRtDZ2SdJnrEXHGGRV_g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] Odd VACUUM behavior when it is expected to truncate last empty pages (Pavan Deolasee <pavan.deolasee@gmail.com>) |
Список | pgsql-hackers |
Thank you very much, your explanation helped a lot. This is the tool I needed the solution for http://code.google.com/p/pc-tools/ if you are interested. On 4 August 2011 01:10, Pavan Deolasee <pavan.deolasee@gmail.com> wrote: > On Wed, Aug 3, 2011 at 12:33 PM, Pavan Deolasee > <pavan.deolasee@gmail.com> wrote: >> >> >> The only problem, other than a surprising behavior that you noted, >> that I see with this approach is that we might repeatedly try to >> truncate a relation which in fact does not have anything to truncate. >> The worst thing is we might unnecessarily take an exclusive lock on >> the table. >> > > So it seems we tried to fix this issue sometime back > http://archives.postgresql.org/pgsql-hackers/2008-12/msg01994.php > > But I don't quite understand how the fix would really work. > nonempty_pages would most likely be set at a value lower than relpages > if the last page in the relation is all-visible according to the > visibility map. Did we mean to test (nonempty_pages > 0) there ? But > even that may not work except for the case when there are no dead > tuples in the relation. > > Thanks, > Pavan > > -- > Pavan Deolasee > EnterpriseDB http://www.enterprisedb.com > -- Sergey Konoplev Blog: http://gray-hemp.blogspot.com / Linkedin: http://ru.linkedin.com/in/grayhemp / JID/GTalk: gray.ru@gmail.com / Skype: gray-hemp
В списке pgsql-hackers по дате отправления: