Some oversights in query_id calculation

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Some oversights in query_id calculation
Date: 2021-04-25 08:11:19
Message-ID: 20210425081119.ulyzxqz23ueh3wuj@nol
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

While doing some sanity checks on the regression tests, I found some queries
that are semantically different but end up with identical query_id.

Two are an old issues:

- the "ONLY" in FROM [ONLY] isn't hashed
- the agglevelsup field in GROUPING isn't hashed

Another one was introduced in pg13 with the WITH TIES not being hashed.

The last one new in pg14: the "DISTINCT" in "GROUP BY [DISTINCT]" isn't hash.

I'm attaching a patch that fixes those, with regression tests to reproduce each
problem.

There are also 2 additional debatable cases on whether this is a semantic
difference or not:

- aliases aren't hashed. That's usually not a problem, except when you use
row_to_json(), since you'll get different keys

- the NAME in XmlExpr (eg: xmlpi(NAME foo,...)) isn't hashed, so you generate
different elements

Attachment Content-Type Size
v1-0001-Fix-some-oversights-in-query_id-calculation.patch text/x-diff 6.6 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2021-04-25 08:22:51 Re: compute_query_id and pg_stat_statements
Previous Message Yura Sokolov 2021-04-25 06:48:52 Re: Use simplehash.h instead of dynahash in SMgr