Re: RangeTblEntry jumble omissions

2024-02-29 Thread Peter Eisentraut
On 26.02.24 02:08, Michael Paquier wrote: On Fri, Feb 23, 2024 at 06:52:54PM -0500, Tom Lane wrote: Julien Rouhaud writes: On Fri, Feb 23, 2024 at 04:26:53PM +0100, Peter Eisentraut wrote: - funcordinality This was probably just forgotten. It should be included because the WITH ORDINALITY cl

Re: RangeTblEntry jumble omissions

2024-02-25 Thread Michael Paquier
On Fri, Feb 23, 2024 at 06:52:54PM -0500, Tom Lane wrote: > Julien Rouhaud writes: >> On Fri, Feb 23, 2024 at 04:26:53PM +0100, Peter Eisentraut wrote: >>> - funcordinality >>> This was probably just forgotten. It should be included because the WITH >>> ORDINALITY clause changes the query result.

Re: RangeTblEntry jumble omissions

2024-02-25 Thread Julien Rouhaud
On Fri, Feb 23, 2024 at 11:00:41PM +0100, Alvaro Herrera wrote: > > 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_

Re: RangeTblEntry jumble omissions

2024-02-25 Thread Alvaro Herrera
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 > f

Re: RangeTblEntry jumble omissions

2024-02-23 Thread Tom Lane
Julien Rouhaud writes: > On Fri, Feb 23, 2024 at 04:26:53PM +0100, Peter Eisentraut wrote: >> - funcordinality >> This was probably just forgotten. It should be included because the WITH >> ORDINALITY clause changes the query result. > Agreed. Seems OK. >> - lateral >> Also probably forgotten.

Re: RangeTblEntry jumble omissions

2024-02-23 Thread Julien Rouhaud
Hi, On Fri, Feb 23, 2024 at 04:26:53PM +0100, 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, s