On 12/2/2018 2:22 AM, legrand legrand wrote:
> I'm also very interested by collecting "search_path" information for
> statements,
> but this information may not be unique for pg_stat_statements key
> (dbid,userid,queryid) ...
>
> How would this 1-N relation be handled ?
> 1/ just catch initial session_info for each (dbid,userid,queryid),
> 2/ adding a sessid field in pgss key, and a table for distinct
> sessid,session_info values,
> 3/ store session_info in an array,
> 4/ ...
>
According to documentation queryid is an "Internal hash code, computed
from the statement's parse tree"
so I expect it to be different for the same query with different
current_schemas or current_user
outside of the possible hash collisions if the changes current_schemas
or current_user in ant way affect the execution of the query.
Queryid can be different even for the same combination of
pg_stat_statements.query + pg_stat_statements.session_info (objects can
be dropped and recreated etc.)
I would say that option 1 makes the most sense.
When a user or an application changes search_path or session_user he/she
expects that it will affect the execution of at least some queries,
that's why these setting were introduced in the first place.
If you know that you execute the same queries on the different schemas
then you would like to group your statistics by query+current_schemas.
If you know that you change current_user for row level security then you
would like to group your statistics by query+current_user.
But you need to preserve this session_info for every queryid in
pg_stat_statements.
Thank you,
Sergei