On 2014-10-11 06:49:54 +0530, Amit Kapila wrote: > On Sat, Oct 11, 2014 at 6:29 AM, Andres Freund <and...@2ndquadrant.com> > wrote: > > > > On 2014-10-11 06:18:11 +0530, Amit Kapila wrote: > > I've run some short tests on hydra: > > > > scale 1000: > > > > base: > > 4GB: > > tps = 296273.004800 (including connections establishing) > > tps = 296373.978100 (excluding connections establishing) > > > > 8GB: > > tps = 338001.455970 (including connections establishing) > > tps = 338177.439106 (excluding connections establishing) > > > > base + freelist: > > 4GB: > > tps = 297057.523528 (including connections establishing) > > tps = 297156.987418 (excluding connections establishing) > > > > 8GB: > > tps = 335123.867097 (including connections establishing) > > tps = 335239.122472 (excluding connections establishing) > > > > base + LW_SHARED: > > 4GB: > > tps = 296262.164455 (including connections establishing) > > tps = 296357.524819 (excluding connections establishing) > > 8GB: > > tps = 336988.744742 (including connections establishing) > > tps = 337097.836395 (excluding connections establishing) > > > > base + LW_SHARED + freelist: > > 4GB: > > tps = 296887.981743 (including connections establishing) > > tps = 296980.231853 (excluding connections establishing) > > > > 8GB: > > tps = 345049.062898 (including connections establishing) > > tps = 345161.947055 (excluding connections establishing) > > > > I've also run some preliminary tests using scale=3000 - and I couldn't > > see a performance difference either. > > > > Note that all these are noticeably faster than your results. > > What is the client count?
160, because that was the one you reported the biggest regression. > Could you please post numbers you are getting for 3000 scale > factor for client count 128 and 175? Yes, although not tonight.... Also from hydra? > > > Nothing specific, for performance tests where I have to take profiles > > > I use below: > > > ./configure --prefix=<installation_path> > CFLAGS="-fno-omit-frame-pointer" > > > make > > > > Hah. Doing so overwrites the CFLAGS configure normally sets. Check > > # CFLAGS are selected so: > > # If the user specifies something in the environment, that is used. > > # else: If the template file set something, that is used. > > # else: If coverage was enabled, don't set anything. > > # else: If the compiler is GCC, then we use -O2. > > # else: If the compiler is something else, then we use -O, unless > debugging. > > > > so, if you do like above, you're compiling without optimizations... So, > > include at least -O2 as well. > > Hmm. okay, but is this required when we do actual performance > tests, because for that currently I don't use CFLAGS. I'm not sure what you mean? You need to include -O2 in CFLAGS whenever you override it. Your profile was clearly without inlining... And since your general performance numbers are a fair bit lower than what I see with, hopefully, the same code on the same machine... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
