Re: [GENERAL] Odd VACUUM behavior when it is expected to truncate last empty pages

From: Sergey Konoplev <gray(dot)ru(at)gmail(dot)com>
To: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Subject: Re: [GENERAL] Odd VACUUM behavior when it is expected to truncate last empty pages
Date: 2011-08-05 03:54:21
Message-ID: CAL_0b1uQcZx+KScZFiE4BBj7ZHT6kgrRtDZ2SdJnrEXHGGRV_g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general 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(dot)deolasee(at)gmail(dot)com> wrote:
> On Wed, Aug 3, 2011 at 12:33 PM, Pavan Deolasee
> <pavan(dot)deolasee(at)gmail(dot)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(dot)ru(at)gmail(dot)com / Skype: gray-hemp

In response to

Browse pgsql-general by date

  From Date Subject
Next Message senthilnathan 2011-08-05 05:05:40 Overhead on while doing pg_start_backup
Previous Message David Johnston 2011-08-04 22:54:56 Re: Is there a better way to unnest an entire row?

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2011-08-05 05:16:57 Re: Reduce WAL logging of INSERT SELECT
Previous Message Alex Hunsaker 2011-08-05 03:23:49 Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https