On 2/19/19 12:43 AM, Tsunakawa, Takayuki wrote: > Hi Horiguchi-san, > > I've looked through your patches. This is the first part of my review > results. Let me post the rest after another work today. > > BTW, how about merging 0003 and 0005, and separating and deferring 0004 in > another thread? That may help to relieve other community members by making > this patch set not so large and complex. > > > > [Bottleneck investigation] > Ideriha-san and I are trying to find the bottleneck. My first try shows > there's little overhead. Here's what I did: > > <postgresql.conf> > shared_buffers = 1GB > catalog_cache_prune_min_age = -1 > catalog_cache_max_size = 10MB > > <benchmark> > $ pgbench -i -s 10 > $ pg_ctl stop and then start > $ cache all data in shared buffers by running pg_prewarm on branches, > tellers, accounts, and their indexes > $ pgbench --select-only -c 1 -T 60 > > <result> > master : 8612 tps > patched: 8553 tps (-0.7%) > > There's little (0.7%) performance overhead with: > * one additional dlist_move_tail() in every catcache access > * memory usage accounting in operations other than catcache access (relevant > catcache entries should be cached in the first pgbench transaction) > > I'll check other patterns to find out how big overhead there is. >
0.7% may easily be just a noise, possibly due to differences in layout of the binary. How many runs? What was the variability of the results between runs? What hardware was this tested on? FWIW I doubt tests with such small small schema are proving anything - the cache/lists are likely tiny. That's why I tested with much larger number of relations. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
