Re: [PATCH] add --progress option to pgbench (submission 3)
От | Tom Lane |
---|---|
Тема | Re: [PATCH] add --progress option to pgbench (submission 3) |
Дата | |
Msg-id | 24846.1372352618@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCH] add --progress option to pgbench (submission 3) (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: [PATCH] add --progress option to pgbench (submission
3)
|
Список | pgsql-hackers |
Fabien COELHO <coelho@cri.ensmp.fr> writes: >>> Here is a v4 that takes into account most of your points: The report is >>> performed for all threads by thread 0, however --progress is not supported >>> under thread fork emulation if there are more than one thread. The report >>> time does not slip anymore. >> I don't believe that to be an acceptable restriction. > My first proposal is to remove the fork emulation altogether, which would > remove many artificial limitations to pgbench and simplify the code > significantly. That would be an improvement. I would object strongly to that, as it would represent a significant movement of the goalposts on what is required to build Postgres at all, ie platforms on which --enable-thread-safety is unavailable or expensive would be out in the cold. Perhaps that set is approaching empty, but a project that's still standardized on C89 has little business making such a choice IMO. > Otherwise, he simplest possible adaptation, if it is required to have the > progress feature under fork emulation to pass it, is that under "fork > emulation" each processus reports its current progress instead of having a > collective summing. Perhaps that's worth doing. I agree with Fabien that full support of this feature in the process model is more trouble than it's worth, though, and I wouldn't scream loudly if we just didn't support it. --disable-thread-safety doesn't have to be entirely penalty-free. regards, tom lane
В списке pgsql-hackers по дате отправления: