From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | pgsql: Use relation name instead of OID in query jumbling for RangeTblE |
Date: | 2025-03-26 06:21:19 |
Message-ID: | E1txK8c-0012jh-2E@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Use relation name instead of OID in query jumbling for RangeTblEntry
custom_query_jumble (introduced in 5ac462e2b7ac as a node field
attribute) is now assigned to the expanded reference name "eref" of
RangeTblEntry, adding in the query jumble computation the non-qualified
aliased relation name, without the list of column names. The relation
OID is removed from the query jumbling.
The effects of this change can be seen in the tests added by
3430215fe35f, where pg_stat_statements (PGSS) entries are now grouped
using the relation name, ignoring the relation search_path may point at.
For example, these two relations are different, but are now grouped in a
single PGSS entry as they are assigned the same query ID:
CREATE TABLE foo1.tab (a int);
CREATE TABLE foo2.tab (b int);
SET search_path = 'foo1';
SELECT count(*) FROM tab;
SET search_path = 'foo2';
SELECT count(*) FROM tab;
SELECT count(*) FROM foo1.tab;
SELECT count(*) FROM foo2.tab;
SELECT query, calls FROM pg_stat_statements WHERE query ~ 'FROM tab';
query | calls
--------------------------+-------
SELECT count(*) FROM tab | 4
(1 row)
It is still possible to use an alias in the FROM clause to split these.
This behavior is useful for relations re-created with the same name,
where queries based on such relations would be grouped in the same
PGSS entry. For permanent schemas, it should not really matter in
practice. The main benefit is for workloads that use a lot of temporary
relations, which are usually re-created with the same name continuously.
These can be a heavy source of bloat in PGSS depending on the workload.
Such entries can now be grouped together, improving the user experience.
The original idea from Christoph Berg used catalog lookups to find
temporary relations, something that the query jumble has never done, and
it could cause some performance regressions. The idea to use
RangeTblEntry.eref and the relation name, applying the same rules for
all relations, temporary and not temporary, has been proposed by Tom
Lane. The documentation additions have been suggested by Sami Imseih.
Author: Michael Paquier <michael(at)paquier(dot)xyz>
Co-authored-by: Sami Imseih <samimseih(at)gmail(dot)com>
Reviewed-by: Christoph Berg <myon(at)debian(dot)org>
Reviewed-by: Lukas Fittl <lukas(at)fittl(dot)com>
Reviewed-by: Sami Imseih <samimseih(at)gmail(dot)com>
Discussion: https://postgr.es/m/Z9iWXKGwkm8RAC93@msg.df7cb.de
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/787514b30bb7dd0b3484d6cb717e3b9aafc06c4a
Modified Files
--------------
contrib/pg_stat_statements/expected/select.out | 20 ++++++++------------
doc/src/sgml/pgstatstatements.sgml | 9 +++++++--
src/backend/nodes/queryjumblefuncs.c | 19 +++++++++++++++++++
src/include/nodes/parsenodes.h | 11 ++++++++---
4 files changed, 42 insertions(+), 17 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Guo | 2025-03-26 08:47:57 | pgsql: Fix integer-overflow problem in scram_SaltedPassword() |
Previous Message | Peter Eisentraut | 2025-03-26 06:05:31 | pgsql: postgres_fdw: Fix tests on some Windows variants |