Re: RFC: Logging plan of the running query

Hi, hackers!

• The last version of patch is correct applied. It changes 8 files from
/src/backend, and 9 other files.

• I have 1 error and 1 warning during compilation on Mac.

explain.c:4985:25: error: implicit declaration of function
'GetLockMethodLocalHash' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
hash_seq_init(&status, GetLockMethodLocalHash());
explain.c:4985:25: warning: incompatible integer to pointer conversion
passing 'int' to parameter of type 'HTAB *' (aka 'struct HTAB *')
[-Wint-conversion]
hash_seq_init(&status, GetLockMethodLocalHash());

This error doesn't appear at my second machine with Ubuntu.

I found the reason. You delete #ifdef USE_ASSERT_CHECKING from
implementation of function GetLockMethodLocalHash(void), but this ifdef
exists around function declaration. There may be a situation, when
implementation exists without declaration, so files with using of
function produce errors. I create new version of patch with fix of this
problem.

I'm agree that seeing the details of a query is a useful feature, but I
have several doubts:

1) There are lots of changes of core's code. But not all users need this
functionality. So adding this functionality like extension seemed more
reasonable.

2) There are many tools available to monitor the status of a query. How
much do we need another one? For example:
• pg_stat_progress_* is set of views with current status of ANALYZE,
CREATE INDEX, VACUUM, CLUSTER, COPY, Base Backup. You can find it in
PostgreSQL documentation [1].
• pg_query_state is contrib with 2 patches for core (I hope someday
Community will support adding this patches to PostgreSQL). It contains
function with printing table with pid, full query text, plan and current
progress of every node like momentary EXPLAIN ANALYSE for SELECT,
UPDATE, INSERT, DELETE. So it supports every flags and formats of
EXPLAIN. You can find current version of pg_query_state on github [2].
Also I found old discussion about first version of it in Community [3].

3) Have you measured the overload of your feature? It would be really
interesting to know the changes in speed and performance.

Thank you for working on this issue. I would be glad to continue to
follow the development of this issue.

Links above:
[1] https://www.postgresql.org/docs/current/progress-reporting.html
[2] https://github.com/postgrespro/pg_query_state
[3]
https://www.postgresql.org/message-id/dbfb1a42-ee58-88fd-8d77-550498f52bc5@postgrespro.ru

--
Ekaterina Sokolova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company