> I discovered the current state of queryId reporting and found that it > may be unlogical: Postgres resets queryId right before query execution > in simple protocol and doesn't reset it at all in extended protocol and > other ways to execute queries.
In exec_parse_message, exec_bind_message and exec_execute_message, the queryId is reset via pgstat_report_activity > I think we should generally report it when the backend executes a job > related to the query with that queryId. This means it would reset the > queryId at the end of the query execution. When the query completes execution and the session goes into a state other than "active", both the query text and the queryId should be of the last executed statement. This is the documented behavior, and I believe it's the correct behavior. If we reset queryId at the end of execution, this behavior breaks. Right? > This seems logical, but > what about the planning process? If an extension plans a query without > the intention to execute it for speculative reasons, should we still > show the queryId? Perhaps we should reset the state right after planning > to accurately reflect the current queryId. I think you are suggesting that during planning, the queryId of the current statement being planned should not be reported. If my understanding is correct, I don't think that is a good idea. Tools that snasphot pg_stat_activity will not be able to account for the queryId during planning. This could mean that certain load on the database cannot be tied back to a specific queryId. Regards, Sami