Re: Using read_stream in index vacuum - Mailing list pgsql-hackers

I ran the following test with v7-0001-Prototype-B-tree-vacuum-streamlineing.patch 

to measure the performance improvement.

--Table size of approx 2GB (Fits in RAM)

postgres=# create unlogged table x_big as select i from generate_series(1,6e7) i;
SELECT 60000000
postgres=# create index on x_big(i);
CREATE INDEX
-- Perform updates to create dead tuples.
postgres=# do $$
declare
    var int := 0;
begin
  for counter in 1 .. 1e7 loop

        var := (SELECT floor(random() * (1e7 - 1 + 1) * 1));
        UPDATE x_big SET i = i + 5 WHERE i = var;
  end loop;
end;
$$;
postgres=# CREATE EXTENSION pg_buffercache;
CREATE EXTENSION
-- Evict Postgres buffer cache for this relation.

postgres=# SELECT DISTINCT pg_buffercache_evict(bufferid)
  FROM pg_buffercache
 WHERE relfilenode = pg_relation_filenode('x_big');
 pg_buffercache_evict
----------------------
 t
(1 row)

postgres=# \timing on
Timing is on.
postgres=# vacuum x_big;
VACUUM

The timing does not seem to have improved with the patch.

Timing with the patch:  Time: 9525.696 ms (00:09.526)

Timing without the patch:  Time: 9468.739 ms (00:09.469) 

While writing this email, I realized I evicted buffers for the table

and not the index. I will perform the test again. However,

I would like to know your opinion on whether this looks like

a valid test.

Thank you,

Rahila Syed