Set visibility map bit after HOT prune

From: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Set visibility map bit after HOT prune
Date: 2012-12-15 12:42:13
Message-ID: CABOikdN3_FFb4qbaSrNhn-SCV2kNS63aGVimRbUzvS9YUFVHNQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

We discussed this idea in the past [1] and Robert recently again
mentioned this in another thread [2]. Please see a rebased/revised
patch attached with the mail. This is mostly similar to what I's
submitted in [1] except some additions to also compute visibility
cut-off XID. I also removed a warning that I'd added to the previous
patch to report the case when the page's all-visible bit is already
set, but our HOT prune scan finds it otherwise. This is not to hide
the warning the earlier reviewer had reported, but I think its not
required because we do those consistency checks at other places
anyways.

I've run several rounds of pgbench (-s 10 -c 10 -T 300) and did not
find any issues. I don't see noticeable performance again/drop. But
again pgbench may not be the most suitable test benchmark to test
this. I think we will see positive differences in vacuum scans and
also queries that are benefited from index-only scans. An early
setting of the visibility map bit can help those two scenarios.

Thanks,
Pavan

1. http://archives.postgresql.org/pgsql-hackers/2010-02/msg02344.php
2. http://archives.postgresql.org/message-id/CA+TgmoZHWN1+N_CGD3hx=DJPHkd69c8x2r2EiQ5=c8yxNrc8wA@mail.gmail.com

--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee

Attachment Content-Type Size
hot-prune-set-all-visible-v2.patch application/octet-stream 7.4 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2012-12-15 13:10:02 Re: small pg_basebackup display bug
Previous Message Cédric Villemain 2012-12-15 12:35:16 Re: Makefiles don't seem to remember to rebuild everything anymore