Re: getting rid of "thread fork emulation" in pgbench?
От | Fabien COELHO |
---|---|
Тема | Re: getting rid of "thread fork emulation" in pgbench? |
Дата | |
Msg-id | alpine.DEB.2.10.1503291919540.17117@sto обсуждение исходный текст |
Ответ на | Re: getting rid of "thread fork emulation" in pgbench? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: getting rid of "thread fork emulation" in pgbench?
Re: getting rid of "thread fork emulation" in pgbench? |
Список | pgsql-hackers |
Hello Tom, >> My question is: would someone still object strongly to the removal of this >> "thread fork emulation" hack in pgbench? > > By my count, the pthread-emulation code amounts to about 175 lines out of > the nearly 4000 in pgbench.c. That's not an undue burden IMO (it's not, > for comparison's sake, very much more than the amount of WIN32-specific > code in that file). From my point of view, the burden is how things can be implemented if you have to assume "no threads". In the discussion at hand which motivates this renewed request, the question is whether external merge sorts implying rescanning and reprinting files over and over should be implemented in pgbench so as to recombine log files. Now if we have threads, it is simpler (if the overhead is reasonable) that threads share a file handle and just generate one file, so there is no merging. That is not possible with processes at least for the aggregated logs because the thread data must be combined, or would require that pgbench use shared memory and so on, but then it is really a lot of bother for a limited feature. The alternative is that the feature would not be available if no thread, but then people object to that, on principle. > And what will you do instead? It would be fine I think for pgbench to > not allow --jobs different from 1 on a threadless platform, but not for > it to fail to work altogether. Sure. No thread really means working with only one thread. > It looks to me like allowing it to compile without that code would take > nearly as much effort/mess as what's there now. My motivation is to simplify how things are done by simply assuming that threads are available and can share data, esp for counters. >> So the underlying question is, does Tom and Robert's opinion have changed >> from 2 years ago? > > Not mine. Ok! I'll ask again in 2017, and probably again in 2019:-) -- Fabien.
В списке pgsql-hackers по дате отправления: