Re: RangeTblEntry jumble omissions

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: RangeTblEntry jumble omissions
Дата
Msg-id hch2t77vh7yrk7hfj26yl4rsu5bshxobvbpjkr3omdx3tmjxer@qfyldwl63lbm
обсуждение исходный текст
Ответ на RangeTblEntry jumble omissions  (Peter Eisentraut <peter@eisentraut.org>)
Ответы Re: RangeTblEntry jumble omissions  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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, so here if you are looking
> for the "AS bar" query, you won't find it.

I think this one is intentional.  This alias won't change the query behavior or
the field names so it's good to avoid extraneous entries.  It's true that you
then won't find something matching "AS bar", but it's not something you can
rely on anyway.

If you first execute "select * from t1 as foo" and then "SELECT * FROM t1 AS
foo" then you won't find anything matching "AS foo" either.  There isn't even
any guarantee that the stored query text will be jumbled.

> - join_using_alias
>
> Similar situation, currently
>
> SELECT * FROM t1 JOIN t2 USING (a, b)
> SELECT * FROM t1 JOIN t2 USING (a, b) AS x
>
> are counted together.

IMHO same as above.

> - funcordinality
>
> This was probably just forgotten.  It should be included because the WITH
> ORDINALITY clause changes the query result.

Agreed.

> - lateral
>
> Also probably forgotten.  A query specifying LATERAL is clearly different
> from one without it.

Agreed.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: Removing unneeded self joins
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Printing backtrace of postgres processes