Re: Record SET session in VariableSetStmt

On Thu, Oct 06, 2022 at 02:19:32PM +0200, Drouvot, Bertrand wrote:
>
> On 10/6/22 1:18 PM, Julien Rouhaud wrote:
>
> > so
> > nothing should rely on how exactly someone spelled it. This is also the case
> > for our core jumbling code, where we guarantee (or at least try to) that two
> > semantically identical statements will get the same queryid, and therefore
> > don't distinguish eg. LIKE vs ~~.
>
> Agree, but on the other hand currently SET and SET SESSION are recorded with
> distinct queryid:
>
> postgres=# select calls, query, queryid from pg_stat_statements;
> calls | query | queryid
> -------+---------------------------------------------+----------------------
> 2 | select calls, query from pg_stat_statements | -6345508659980235519
> 1 | set session enable_seqscan=1 | -3921418831612111986
> 1 | create extension pg_stat_statements | -1739183385080879393
> 1 | set enable_seqscan=1 | 7925920505912025406
> (4 rows)
>
> and this behavior would change with the Jumbling work in progress in [1]
> (mentioned up-thread) if we don't record "SET SESSION".
>
> I think that would make sense to keep the same behavior, what do you think?

It's because until now jumbling of utility statements was just hashing the
query text, which is quite terrible. This was also implying getting different
queryids for things like this:

=# select query, queryid from pg_stat_statements where query like '%work_mem%';;
query | queryid
-----------------------+----------------------
SeT work_mem = 123465 | -1114638544275583196
Set work_mem = 123465 | -1966597613643458788
SET work_mem = 123465 | 4161441071081149574
seT work_mem = 123465 | 8327271737593275474
(4 rows)

If we move to a real jumbling of VariableSetStmt, we should keep the rules
consistent with the rest of the jumble code and ignore an explicit "SESSION" in
the original command.