From: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> |
---|---|
To: | "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | "Zdenek Kotala" <Zdenek(dot)Kotala(at)sun(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: visibility maps |
Date: | 2008-12-11 16:09:44 |
Message-ID: | 2e78013d0812110809q5a656eabu51960ba8fb7282f3@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Dec 11, 2008 at 8:09 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>
>
> I'm not sure if we should set the bits in very aggressively. If we're more
> aggressive about setting the bits, it also means that we have to clear the
> bits more often, increasing the likelihood of contention that you were
> worried about.
Well, I would rather set bits aggressively and reduce contention by
changing the lock type. If HOT is working well, VACUUM will have very
few things to do, but visibility map wouldn't help as much as it can
unless we set the bits after pruning.
Another thing I noticed is the since VACUUM tries to set the bit in
the first phase, it's working only because HOT prunes DEAD tuples just
before we do another scan on line pointers (which I had earlier talked
about getting rid of. May be its time I do that). Otherwise, the
visibility bit won't be set even though the DEAD tuples will be
removed in the second scan and the rest are all LIVE tuples. So if we
at all want to take out the another scan of line pointers from the
first pass, we should rather push the work setting bits in the prune
code.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2008-12-11 16:11:49 | Re: Updates of SE-PostgreSQL 8.4devel patches (r1268) |
Previous Message | Peter Eisentraut | 2008-12-11 16:08:38 | Re: Updates of SE-PostgreSQL 8.4devel patches (r1268) |