This patch affects header files. By any chance didn't you forget to run `make clean` after applying it? As we discussed above, when you change .h files autotools doesn't rebuild dependent .c files:
http://www.postgresql.org/message-id/caf4au4y4mtapp2u3ugtbqd_z0chesjwfnavrgk4umfcwa4e...@mail.gmail.com On Thu, 21 Jan 2016 16:49:12 +0530 Dilip Kumar <dilipbal...@gmail.com> wrote: > On Tue, Jan 12, 2016 at 1:50 PM, Aleksander Alekseev < > a.aleks...@postgrespro.ru> wrote: > > > > > increasing number of lock partitions (see columns "no locks", > > "lwlock" and "spinlock array"). Previously it couldn't help us (see > > "master" column) because of a bottleneck. > > > > If you have any other questions regarding this patch please don't > > hesitate to ask. > > > > I have done some performance bench marking for this > patch.(dynahash-optimization-v10-step1.patch) > > Machine Detail: > cpu : POWER8 > cores: 24 (192 with HT) > > Non Default Parameter: > ------------------------ > Shared Buffer= 30GB > max_wal_size= 10GB > max_connections=500 > > Test1: > *schema.sql* and *pgbench.sql* are same files which Aleksander has > attached in first mail of the thread. > > psql -d postgres -f schema.sql > pgbench -c$ -j$ -f pgbench.sql postgres > > client base patch > 1 145 145 > 2 262 258 > 4 453 472 > 8 749 732 > 16 1114 1128 > 32 1727 1789 > 64 2729 2793 > 128 3534 3520 > > With this test i did not see any improvement, though i think it should > improve the performance, do you have any suggestion to see the > results same as yours ? > > I have also dump stacks using some script and I have observed many > stacks dumps as you mentioned in initial thread. And after patch, I > found that number of lock waiting stacks are reduced. > > Stack Dump: > ------------------- > #0 0x00007f25842899a7 in semop () from /lib64/libc.so.6 > #1 0x00000000007116d0 in PGSemaphoreLock (sema=0x7f257cb170d8) at > pg_sema.c:387 > #2 0x000000000078955f in LWLockAcquire (lock=0x7f247698a980, > mode=LW_EXCLUSIVE) at lwlock.c:1028 > #3 0x00000000007804c4 in LockAcquireExtended > #4 0x000000000077fe91 in LockAcquire > #5 0x000000000077e862 in LockRelationOid > #6 0x000000000053bc7b in find_inheritance_children > #7 0x000000000053bd4f in find_all_inheritors > #8 0x00000000006fc0a2 in expand_inherited_rtentry > #9 0x00000000006fbf91 in expand_inherited_tables > > I have tried to analyze using perf also, I can see that amount of time > taken in hash_search_with_hash_value is reduced from 3.86%(master) to > 1.72%(patch). > > I have plan to do further investigation, in different scenarios of > dynahash. > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
