Re: Postgres with pthread - Mailing list pgsql-hackers

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.