On Tue, 2009-03-17 at 19:54 -0400, Jignesh K. Shah wrote: > > Simon Riggs wrote: > > On Tue, 2009-03-17 at 17:41 -0400, Jignesh K. Shah wrote: > > > > > >> I did a quick test with patch. Unfortunately it improves my number > >> even with default setting 0 (not sure whether I should be pleased or > >> sad - Definitely no overhead infact seems to help performance a bit. > >> NOTE: Logic is same, implementation is slightly different for default > >> set) > >> > > > > OK, I bite. 25% gain from doing nothing??? You're stretching my... err, > > credulity. > > > > I like the train of thought for setting 1 and it is worth investigating, > > but something feels wrong somewhere. > > > > > Actually I think I am hurting my credibility here since I cannot > explain the improvement with the patch but still using default logic > (thought different way I compare sequential using fields from the > previous proc structure instead of comparing with constant boolean) > But the change was necessary to allow it to handle multiple algorithms > and yet be sleek and not bloated. > > In next couple of weeks I plan to test the patch on a different x64 > based system to do a sanity testing on lower number of cores and also > try out other workloads ... Good plan. I'm behind your ideas and will be happy to wait. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support - Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
