Re: RangeTblEntry jumble omissions

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RangeTblEntry jumble omissions
Date: 2024-02-23 22:00:41
Message-ID: 202402232200.msal7gqyyexg@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2024-Feb-23, Peter Eisentraut wrote:

> - alias
>
> Currently, two queries like
>
> SELECT * FROM t1 AS foo
> SELECT * FROM t1 AS bar
>
> are counted together by pg_stat_statements -- that might be ok, but they
> both get listed under whichever one is run first, so here if you are looking
> for the "AS bar" query, you won't find it.

Another, similar but not quite: if you do

SET search_path TO foo;
SELECT * FROM t1;
SET search_path TO bar;
SELECT * FROM t1;

and you have both foo.t1 and bar.t1, you'll get two identical-looking
queries in pg_stat_statements with different jumble IDs, with no way to
know which is which. Not sure if the jumbling of the RTE (which
includes the OID of the table in question) itself is to blame, or
whether we want to store the relevant schemas with the entry somehow, or
what. Obviously, failing to differentiate them would not be an
improvement.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2024-02-23 22:03:01 Re: Running the fdw test from the terminal crashes into the core-dump
Previous Message Nathan Bossart 2024-02-23 21:52:16 Re: cleanup patches for dshash