On Mon, May 19, 2025 at 09:07:35AM +0200, Daniel Verite wrote:
> That looks normal. The unicity to expect is on
> (queryid, userid, dbid, toplevel).
>
> From https://www.postgresql.org/docs/current/pgstatstatements.html :
>
> This view contains one row for each distinct combination of database
Jevon Cowell wrote:
> What I'm seeing is that for the same query *and* query id,
> there are two rows with different statistics data *at the same time*. For
> example one row can have 2 calls while another can have 4
That looks normal. The unicity to expect is on
(queryid, userid, dbid,
On 5/18/25 12:20, Jevon Cowell wrote:
Hi Folks!
Let me know if there's a better mailing list to ask this in.
I have a statistics collector that collects data from various postgres
statistics tables, pg_stat_statements being one of them. This is done on
an entire fleet of Postgres databases. Fr
On Tue, 3 Oct 2023 at 22:03, wrote:
> So one last question, should I expect the patch to land in version 17 only or
> is there chance that it will also be in lower versions right away?
It wouldn't ever be put into anything earlier than 17.
David
Thank you very much Laurenz and David. Looking forward to it and unfortunatelly
no, I am not in position to review that...
So one last question, should I expect the patch to land in version 17 only or
is there chance that it will also be in lower versions right away?
LJ
Sent with Proton Mai
On Tue, 2023-10-03 at 08:05 +, byme@byme.email wrote:
> "This obfuscates our monitoring because the same query with different amount
> of arguments gets translated into this:
> IN ($1, $2)
> and so on."
>
> The questions are:
> 1. Shouldnt IN behave so that the query in pg_stat_statements wou
On Tue, 3 Oct 2023 at 21:07, wrote:
> P.S.: The only serious discussion I was able to find about it was from 2015
> here, everyone basically stating that the improvement would be useful.
> https://postgrespro.com/list/thread-id/1880012
There is some active discussion and a patch which aims to i
Thank you for response. Unfortunately, I have to update one section which I
wrote wrong, it should have
been this way:
"This obfuscates our monitoring because the same query with different amount of
arguments gets translated into this:
IN ($1, $2)
and so on."
The questions are:
1. Shouldnt IN b
byme@byme.email schreef op ma 02-10-2023 om 16:19 [+]:
>
>
> Is there a possibility the pg_stat_statements will be improved with
> handling IN? This problem makes it so much less useful right now.
not sure what the question is,
but if you change pg_stat_statements with another view/table,
th
On Wed, 12 Jan 2022 at 13:17, Simon Riggs wrote:
>
> On Wed, 12 Jan 2022 at 10:31, Julien Rouhaud wrote:
> >
> > On Wed, Jan 12, 2022 at 10:22:38AM +, Simon Riggs wrote:
> > > On Wed, 12 Jan 2022 at 03:03, Julien Rouhaud wrote:
> > > >
> > > > Unfortunately this is a known limitation.
> > >
On Wed, 12 Jan 2022 at 10:31, Julien Rouhaud wrote:
>
> On Wed, Jan 12, 2022 at 10:22:38AM +, Simon Riggs wrote:
> > On Wed, 12 Jan 2022 at 03:03, Julien Rouhaud wrote:
> > >
> > > Unfortunately this is a known limitation.
> >
> > I see this as a beneficial feature.
> >
> > If the same SQL is
On Wed, Jan 12, 2022 at 10:22:38AM +, Simon Riggs wrote:
> On Wed, 12 Jan 2022 at 03:03, Julien Rouhaud wrote:
> >
> > Unfortunately this is a known limitation.
>
> I see this as a beneficial feature.
>
> If the same SQL is executed against different sets of tables, each
> with different ind
On Wed, 12 Jan 2022 at 03:03, Julien Rouhaud wrote:
>
> Hi,
>
> On Tue, Jan 11, 2022 at 03:04:14PM +, Dirschel, Steve wrote:
> >
> > I'm not sure if this is the correct distribution list for this type of
> > question but I'll try anyways. We have an app that uses multiple schemas.
> > It will
Hi,
On Tue, Jan 11, 2022 at 03:04:14PM +, Dirschel, Steve wrote:
>
> I'm not sure if this is the correct distribution list for this type of
> question but I'll try anyways. We have an app that uses multiple schemas.
> It will do a set schema 'schema_name' and execute queries. The queries
> e
Tom Lane-2 wrote
> legrand legrand <
> legrand_legrand@
> > writes:
>> Tom Lane-2 wrote
>>> The hard part here is that you have to be really careful what you do in
>>> a PG_CATCH block, because the only thing you know for sure about the
>>> backend's state is that it's not good. Catalog fetches
legrand legrand writes:
> Tom Lane-2 wrote
>> The hard part here is that you have to be really careful what you do in
>> a PG_CATCH block, because the only thing you know for sure about the
>> backend's state is that it's not good. Catalog fetches are right out,
>> and anything that might itself
Tom Lane-2 wrote
> legrand legrand <
> legrand_legrand@
> > writes:
>> So the only solution is to had queryId to ErrorData in this hook
>> or create a new hook fired on ERROR and containing queryId ?
>
> I see no particular need for a new hook. What's needed here is for
> pgss_ExecutorRun (and
On 13 January 2020 20:15:21 CET, Rushikesh socha wrote:
>HI, Is there any good link that shows how to install pg_stat_statements
>extension
>I am getting below error
>
>postgres=# CREATE EXTENSION pg_stat_statements;
>ERROR: could not open extension control file
>"/usr/pgsql-11/share/extension/pg
On Mon, Jan 13, 2020 at 11:41:36AM -0800, Adrian Klaver wrote:
> How did the above get installed, from source, RPM. other?
Rushikesh, depending on your environment, the way to install
pg_stat_statements' libraries may change. On most Linux
distributions, any extension modules are shipped with a p
On 1/13/20 11:29 AM, Rushikesh socha wrote:
HI its 11.5
version
-
PostgreSQL 11.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5
201506
HI its 11.5
version
-
PostgreSQL 11.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5
20150623 (Red Hat 4.8.5-36), 64-bit
Thanks.
Rushikesh
On 1/13/20 11:15 AM, Rushikesh socha wrote:
HI, Is there any good link that shows how to install pg_stat_statements
extension
Postgres version?
How did you install Postgres?
I am getting below error
postgres=# CREATE EXTENSION pg_stat_statements;
ERROR: could not open extension control fil
forgot to cc pgsql-general list
De : legrand legrand
Envoyé : vendredi 22 février 2019 20:26
À : Bruce Momjian
Objet : RE: pg_stat_statements doesn't track commit from pl/pgsql blocks
Hello Bruce,
thank you for taking time to answer.
yes, I was expe
On Sun, Feb 17, 2019 at 02:52:07PM -0700, legrand legrand wrote:
> Hello,
>
> It seems that pgss doesn't track commit (nor rollback) commands from
> pl/pgsql blocks.
> using psql in version 11.1:
>
> select pg_stat_statements_reset();
> do $$ begin commit; end $$;
> select calls,query from pg_sta
I don't agree.
If we already had a column with the execution plan in the
pg_stat_statements then
it would be a workaround for the problem with the ambiguous names in the
query text column.
But we don't have such column, and I don't want to create a dependency
on the unimplemented feature.
I rat
I like it. I don't want to break backward compatibility.
The new column could be named like query_qn, and will have here the
unambitious text of the query
where all the objects names are extended to the qualified names.
Sergei Agalakov
On 11/27/2018 2:17 PM, Alvaro Herrera wrote:
On 2018-Nov-
On 2018-Nov-27, legrand legrand wrote:
> There are also some tryies to extend pg_stat_statements
> with plans see
> https://www.postgresql-archive.org/FEATURE-PATCH-pg-stat-statements-with-plans-td5940964.html
Thread at
http://postgr.es/m/9e43fd8f-4d35-4b9d-545c-f9011cd4a...@uni-muenster.de
-
On 2018-Nov-27, Sergei Agalakov wrote:
> We do see that the queries are different but we can't see why they are so
> much different in the execution time.
> If the pg_stat_statements module would extend the object name to the
> qualified names like s1.t1 and s2.t2 then we would see the report as
>
A part of the answer would be to store
explain (verbose on) select count(*) from t1;
result in pg_stat_statements for the corresponding query...
(Verbose On) gives the "qualified names":
QUERY PLAN
---
Aggregate (cost=19.38..19.39 rows=1 width=8)
Output: c
Hi,
This is the expected behavior, like that sql statements with différent
values are shared in pg_stat_statements ...
There is no parameter to change this, if you really want query paramèters
you néed to have a look at statements logging, but be carrefull this can
generate a huge volume of log fil
Hello,
Here is a patch that :
- adds a new guc: pg_stat_statements.track_errors boolean (default to true),
- capture of DML, DDL, PL/PGSQL commands in error into pgss.
There is always a risk that new code used in PG_CATCH (mainly pgss_store)
gives an error.
I'm not able to tell when it could occ
Progress report on this subject:
1/ Some clarifications:
What is expected here is to update pgss counters for ALL the queries that
have been executed,
taking into account queries finished in SUCCESS and thoses finised with
ERROR.
Main interest here is to catch queries that are cancelled or inte
OK no need of a new hook.
I'll try to implement what you suggest here, but this clearly exceeds my
(poor) development skill.
As you also noticed, in addition to collect this SQL statement counters for
the corresponding QueryId,
I would have been interested in its PlanId ... but it's an other subj
legrand legrand writes:
> So the only solution is to had queryId to ErrorData in this hook
> or create a new hook fired on ERROR and containing queryId ?
I see no particular need for a new hook. What's needed here is for
pgss_ExecutorRun (and maybe some other existing functions in
pg_stat_statem
OK I see ...
This hook should be used only for ERROR (no WARNING nor NOTICE ...)
and the only real interesting information is
ErrorData -> internalquery; /* text of internally-generated query */
This doesn't permit to (re)build the link to queryid
(that is based on parse tree, but not availa
Hello,
On Thu, Apr 26, 2018 at 01:24:25PM -0700, legrand legrand wrote:
> Hello all,
>
> I was wondering if there is a hook to collect non successfully finished SQL
> statements in pg_stat_statements (timed-out, cancelled, killed, or simply
> errored) ?
Some time ago I looked for a such hook. My
On Sat, Mar 24, 2018 at 12:17:30PM +1300, David Rowley wrote:
> If it is, then it's not a bug in pg_stat_statements. log_statement =
> 'ddl' would have kept a record of the same thing.
>
> Perhaps the best fix would be a documentation improvement to mention
> the fact and that it's best not to use
On 24 March 2018 at 10:30, legrand legrand wrote:
> It seems that passwords used in commands are not removed when caught by
> pg_stat_statements
> (they are not "normalized" being utility statements)
>
> exemple:
> alter role tt with password '123';
>
> select query from public.pg_stat_statements
38 matches
Mail list logo
