Re: Eliminate redundant tuple visibility check in vacuum

> On Tue, Aug 29, 2023 at 5:07 AM David Geier <geidav.pg@gmail.com> wrote:
> > Could you measure any performance difference?
> >
> > If so could you provide your test case?
>
> I created a large table and then updated a tuple on every page in the
> relation and vacuumed it. I saw a consistent slight improvement in
> vacuum execution time. I profiled a bit with perf stat as well. The
> difference is relatively small for this kind of example, but I can
> work on a more compelling, realistic example. I think eliminating the
> retry loop is also useful, as I have heard that users have had to
> cancel vacuums which were in this retry loop for too long.

Just to provide a specific test case, if you create a small table like this

create table foo (a int, b int, c int) with(autovacuum_enabled=false);
insert into foo select i, i, i from generate_series(1, 10000000);

And then vacuum it. I find that with my patch applied I see a
consistent ~9% speedup (averaged across multiple runs).

master: ~533ms
patch: ~487ms

And in the profile, with my patch applied, you notice less time spent
in HeapTupleSatisfiesVacuumHorizon()

master:
    11.83%  postgres  postgres           [.] heap_page_prune
    11.59%  postgres  postgres           [.] heap_prepare_freeze_tuple
     8.77%  postgres  postgres           [.] lazy_scan_prune
     8.01%  postgres  postgres           [.] HeapTupleSatisfiesVacuumHorizon
     7.79%  postgres  postgres           [.] heap_tuple_should_freeze

patch:
    13.41%  postgres  postgres           [.] heap_prepare_freeze_tuple
     9.88%  postgres  postgres           [.] heap_page_prune
     8.61%  postgres  postgres           [.] lazy_scan_prune
     7.00%  postgres  postgres           [.] heap_tuple_should_freeze
     6.43%  postgres  postgres           [.] HeapTupleSatisfiesVacuumHorizon

- Melanie