Re: PATCH: pgbench - merging transaction logs

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: PATCH: pgbench - merging transaction logs
Дата
Msg-id alpine.DEB.2.10.1505021604170.31061@sto
обсуждение исходный текст
Ответ на Re: PATCH: pgbench - merging transaction logs  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-hackers
> It might be done in the other direction, though - the "writer" thread 
> might collect current results at the end of the interval.

Yep, you can indeed accumulate per thread and sum on the end of the 
interval, but a lock is still needed if you want exact figures.

ISTM that it is what is done for --progress, without even bothering to 
lock anything (even if transactions are fast and some inconsistency arise, 
this is just for showing how things are faring on stderr, so no big deal).

>> "fprintf" does a lot of processing, so it is the main issue.
>
> The question is whether the processing happens while holding the lock, 
> though. I don't think that's the case.

Alas I'm pretty nearly sure it is necessarily the case, there is no 
intermediate buffer in fprintf, the buffering is done trough the file 
handler so a lock must be acquire throughout format processing.

https://www.gnu.org/software/libc/manual/html_node/Streams-and-Threads.html#Streams-and-Threads

"The POSIX standard requires that by default the stream operations are 
atomic.  I.e., issuing two stream operations for the same stream in two 
threads at the same time will cause the operations to be executed as if 
they were issued sequentially. The buffer operations performed while 
reading or writing are protected from other uses of the same stream. To do 
this each stream has an internal lock object which has to be (implicitly) 
acquired before any work can be done. "

-- 
Fabien.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: parallel mode and parallel contexts
Следующее
От: Joe Wildish
Дата:
Сообщение: Re: Implementing SQL ASSERTION