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
