> But it is a theory. The main idea of this prototype was to prove or disprove > this expectation at practice.
> But please notice that it is very raw prototype. A lot of stuff is not > working yet. > And supporting all of exited Postgres functionality requires > much more efforts (and even more efforts are needed for optimizing Postgres > for this architecture). > > I just want to receive some feedback and know if community is interested in > any further work in this direction. Looks good. You are right, it is a theory. If your prototype does actually show what we think it does then it is a good and interesting result. I think we need careful analysis to show where these exact gains come from. The actual benefit is likely not evenly distributed across the list of possible benefits. Did they arise because you produced a stripped down version of Postgres? Or did they arise from using threads? It would not be the first time a result shown in protoype did not show real gains on a completed project. I might also read your results to show that connection concentrators would be a better area of work, since 100 connections perform better than 1000 in both cases, so why bother optimising for 1000 connections at all? In which case we should read the benefit at the 100 connections line, where it shows the lower 28% gain, closer to the gain your colleague reported. So I think we don't yet have enough to make a decision. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
