Re: improve DEBUG1 logging of parallel workers for CREATE INDEX?
От | Sami Imseih |
---|---|
Тема | Re: improve DEBUG1 logging of parallel workers for CREATE INDEX? |
Дата | |
Msg-id | CAA5RZ0tTpqUjNc3FcegjW9njZWSPSE0tFN9d4BCLh_c+whgZwA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: improve DEBUG1 logging of parallel workers for CREATE INDEX? (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>) |
Ответы |
Re: improve DEBUG1 logging of parallel workers for CREATE INDEX?
|
Список | pgsql-hackers |
> Hmm. I am reading Tom's opinion that goes toward not going in this > direction for more commands, with the point to extend EXPLAIN to show > this kind of information: > https://www.postgresql.org/message-id/1692530.1736369905@sss.pgh.pa.us That sounds like the ability to do something like EXPLAIN CREATE INDEX ... is that correct? > So do we really want to do what's proposed here? I'm +-0 about the > VERBOSE option attached to more commands, as it is a bit harder for > clients to catch the information wanted. So here comes my question: > how do we want to consume this information at the end from the > perspective of the client? For interactive usage in psql or pgadmin, it's trivial to capture this information. The information can also be written to the server log with log_min_messages=INFO A bit more work is required to redirect messages to an out file from psql, as you need to ensure that stderr is redirected to a file. It's also a bit more work to capture this information from something like a JDBC application. IMO the interactive use-case is where this is the most useful as you can start a CREATE INDEX (VERBOSE) and ensure that it's going to launch all the parallel workers that it planned before letting it it continue; or control-c and figure out why not all planned workers launched. Regards, Sami
В списке pgsql-hackers по дате отправления: