Query jumbling of ROLLUP/CUBE, SEARCH/CYCLE and composite fields

Hi,

In [1], I reported several fields that are not part of the query ID
although they change the results of the queries. Tom replied [2] that
merging sufficiently similar queries has always been the intention of
query jumbling, that whether a field should be jumbled is a judgment
call in each case, and that this needs consensus here, with the benefit
of the doubt probably going to the existing behavior. So I would like
to ask about three of these cases, which look the clearest to me.

There is a precedent in [3]: WITH ORDINALITY was added to the query ID
in 8b29a119fd, as it changes the query result, while aliases and
LATERAL were left out, LATERAL because it only matters through lateral
references, which are already jumbled. In the three cases below, the
queries return different results, and nothing else in the jumbled
query tree differs between them.

1. The kind of grouping set (GroupingSet.kind)

CREATE TABLE t (a int, b int);
INSERT INTO t VALUES (1, 1), (1, 2), (2, 1);
SELECT a, b, count(*) FROM t GROUP BY ROLLUP (a, b);
SELECT a, b, count(*) FROM t GROUP BY CUBE (a, b);
SELECT a, b, count(*) FROM t GROUP BY GROUPING SETS (a, b);

These return 6, 8 and 4 rows, but they are in a single entry:

calls | rows | query
-------+------+-----------------------------------------------------
3 | 18 | SELECT a, b, count(*) FROM t GROUP BY ROLLUP (a, b)

Since grouping sets were added in 9.5, the content of a GroupingSet has
been jumbled but not its kind, and the generated jumbling code kept
this. I could not find any discussion about it. This case looks close
to e217dc7484 [4], after which queries with different GROUP BY
expressions are again in separate entries.

2. The SEARCH and CYCLE clauses of recursive CTEs
(CommonTableExpr.search_clause and cycle_clause)

WITH RECURSIVE r AS (SELECT 1 AS a, 1 AS b
UNION ALL
SELECT a % 3 + 1, b % 2 + 1 FROM r)
CYCLE a SET is_cycle USING path
SELECT a, b FROM r;

This returns 4 rows, and the same query with CYCLE b returns 3 rows, as
the cycle is detected on another column, but both are in one entry. The
same goes for the columns of SEARCH: SEARCH DEPTH FIRST BY with
different columns computes different values of the sequence column, and
the queries are in one entry even when they sort on it. These clauses
are expanded by the rewriter, after the query ID is computed, so they
are not reflected anywhere else in the jumbled query tree. The names of
the columns added by SET and USING are like aliases, so they could still
be left out.

3. Assignments to fields of a composite column (FieldStore.fieldnums)

CREATE TYPE pair AS (x int, y int);
CREATE TABLE t2 (c pair, x int, y int);
UPDATE t2 SET c.x = 1;
UPDATE t2 SET c.y = 1;

These two are in one entry, and so are INSERT INTO t2 (c.x) and
INSERT INTO t2 (c.y), although they change different fields. In
contrast, UPDATE t2 SET x = 1 and UPDATE t2 SET y = 1 are in separate
entries, and so are SELECT (c).x and SELECT (c).y, which read these
fields.

None of these has ever been part of the query ID, so including them
changes query IDs, and this would be for master only. Patches for these
cases are 0004, 0005 and 0008 in [1], on top of the tests in 0001. If
there is agreement on some of them, I will post a new series with only
those, with the tests first.

Thoughts?

[1] https://postgr.es/m/B388C5B3-83C2-44B3-B883-BE72A9E5A2B5@localhost.localdomain
[2] https://postgr.es/m/737423.1793039194@sss.pgh.pa.us
[3] https://postgr.es/m/d7f421f8-fd6d-4759-adc3-247090a5d44b@eisentraut.org
[4] https://postgr.es/m/CACJufxEy2W+tCqC7XuJ94r3ivWsM=onKJp94kRFx3hoARjBeFQ@mail.gmail.com

--
Ilya Staroverov