Re: Query ID Calculation Fix for DISTINCT / ORDER BY and LIMIT / OFFSET - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: Query ID Calculation Fix for DISTINCT / ORDER BY and LIMIT / OFFSET
Date
Msg-id CAA5RZ0uZ8cVO7JT5Xep5ZEByJPGQ5ubme_rY5WCrCvpSPji8Jg@mail.gmail.com
Whole thread Raw
In response to Re: Query ID Calculation Fix for DISTINCT / ORDER BY and LIMIT / OFFSET  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Query ID Calculation Fix for DISTINCT / ORDER BY and LIMIT / OFFSET
List pgsql-hackers
Maybe I am missing something, but when I applied the
v9-0001 patch alone, it did not solve the problem it
claims to and the pg_s_s regression test fails:

+++ /local/home/simseih/pghead/install1/postgresql/contrib/pg_stat_statements/results/select.out
   2025-03-27 04:56:35.143855392 +0000
@@ -215,14 +215,12 @@
      3 |    3 | SELECT $1 + $2 + $3 AS "add"
      1 |    1 | SELECT $1 AS "float"
      2 |    2 | SELECT $1 AS "int"
-     2 |    2 | SELECT $1 AS "int" LIMIT $2
-     2 |    0 | SELECT $1 AS "int" OFFSET $2
+     4 |    2 | SELECT $1 AS "int" LIMIT $2
      6 |    0 | SELECT $1 AS "int" OFFSET $2 LIMIT $3
-     2 |    2 | SELECT $1 AS "int" ORDER BY 1
      1 |    2 | SELECT $1 AS i UNION SELECT $2 ORDER BY i
      1 |    1 | SELECT $1 || $2
      1 |    1 | SELECT $1, $2 LIMIT $3
-     2 |    2 | SELECT DISTINCT $1 AS "int"
+     4 |    4 | SELECT DISTINCT $1 AS "int"
      0 |    0 | SELECT calls, rows, query FROM pg_stat_statements
ORDER BY query COLLATE "C"
      1 |    1 | SELECT pg_stat_statements_reset() IS NOT NULL AS t
      1 |    2 | WITH t(f) AS (
                      +
@@ -230,7 +228,7 @@
        |      | )
                      +
        |      |   SELECT f FROM t ORDER BY f
      1 |    1 | select $1::jsonb ? $2
-(17 rows)
+(15 rows)

but when v9-0002 is applied, the regress tests then
succeed.

--
Sami Imseih
Amazon Web Services (AWS)



pgsql-hackers by date:

Previous
From: Alexander Lakhin
Date:
Subject: Re: Latches vs lwlock contention
Next
From: Ashutosh Bapat
Date:
Subject: Re: [PoC] Reducing planning time when tables have many partitions