Re: heapgettup refactoring - Mailing list pgsql-hackers
From | David Rowley |
---|---|
Subject | Re: heapgettup refactoring |
Date | |
Msg-id | CAApHDvpnA9SGp3OeXr4cYqX_w=NYN2YMzf2zfrABPNDsUqoNqw@mail.gmail.com Whole thread Raw |
In response to | Re: heapgettup refactoring (Melanie Plageman <melanieplageman@gmail.com>) |
List | pgsql-hackers |
On Tue, 31 Jan 2023 at 12:18, Melanie Plageman <melanieplageman@gmail.com> wrote: > > On Fri, Jan 27, 2023 at 10:34 PM David Rowley <dgrowleyml@gmail.com> wrote: > > 4. I think it might be a good idea to use unlikely() in if > > (!scan->rs_inited). The idea is to help coax the compiler into moving > > that code off to a cold path. That's likely especially important if > > heapgettup_initial_block is inlined, which I see it is marked as. > > I've gone ahead and added unlikely. However, should I perhaps skip > inlining the heapgettup_initial_block() function? I'm not sure of the exact best combination of functions to mark as inline. I did try the v7 patchset from 0002 to 0006 on top of c2891175 and I found that the performance is slightly better after removing inline from all 4 of the helper functions. However, I think if we do unlikely() and the function is moved into the cold path then it matters less if it's inlined. create table a (a int); insert into a select x from generate_series(1,1000000)x; vacuum freeze a; $ cat seqscan.sql select * from a where a = 0; $ cat countall.sql select count(*) from a; seqscan.sql filters out all rows and countall.sql returns all rows and does an aggregate so we don't have to return all those in the query. max_parallel_workers_per_gather=0; master $ psql -c "select pg_prewarm('a')" postgres > /dev/null && for i in {1..3}; do pgbench -n -f seqscan.sql -M prepared -T 10 postgres | grep tps; done tps = 25.464091 (without initial connection time) tps = 25.117001 (without initial connection time) tps = 25.141646 (without initial connection time) $ psql -c "select pg_prewarm('a')" postgres > /dev/null && for i in {1..3}; do pgbench -n -f countall.sql -M prepared -T 10 postgres | grep tps; done tps = 27.906307 (without initial connection time) tps = 27.527580 (without initial connection time) tps = 27.563035 (without initial connection time) master + v7 $ psql -c "select pg_prewarm('a')" postgres > /dev/null && for i in {1..3}; do pgbench -n -f seqscan.sql -M prepared -T 10 postgres | grep tps; done tps = 25.920370 (without initial connection time) tps = 25.680052 (without initial connection time) tps = 24.988895 (without initial connection time) $ psql -c "select pg_prewarm('a')" postgres > /dev/null && for i in {1..3}; do pgbench -n -f countall.sql -M prepared -T 10 postgres | grep tps; done tps = 33.783122 (without initial connection time) tps = 33.248571 (without initial connection time) tps = 33.512984 (without initial connection time) master + v7 + inline removed $ psql -c "select pg_prewarm('a')" postgres > /dev/null && for i in {1..3}; do pgbench -n -f seqscan.sql -M prepared -T 10 postgres | grep tps; done tps = 27.680115 (without initial connection time) tps = 26.418562 (without initial connection time) tps = 26.166800 (without initial connection time) $ psql -c "select pg_prewarm('a')" postgres > /dev/null && for i in {1..3}; do pgbench -n -f countall.sql -M prepared -T 10 postgres | grep tps; done tps = 33.948588 (without initial connection time) tps = 33.684966 (without initial connection time) tps = 33.946700 (without initial connection time) You can see that v7 helps countall.sql quite a bit. It seems to also help a little bit with seqscan.sql. v7 + inline removed makes seqscan.sql a decent amount faster than both master and master + v7. David
pgsql-hackers by date: