Hi,
On 2017-11-12 22:28:11 +0000, gregburek@heroku.com wrote:
> I think this is either a bug in how pgss does not account for canceled
> queries that still exert load on a database or in the documentation of pgss
> that it only accounts for completed queries and that statement_timeout or
> app timeouts can result in query undercounting or omissions.
I think the only sane way out of this one is to change the docs. You
could also add some additional tracking feature, but:
> Below is a reproduction of this issue, where a pathologically bad query,
> which is responsible for the bulk of the load executed on the db, does not
> increment or add execution statistics to pg_stat_statements.
>
> I would expect that the final `select * from test order by random() limit
> ?;` entry of pg_stat_statements would have a count equal 7 and total_time
> around 142623.038.
this'd be a horrible idea, because it'd completely skew the cost that
one expects a single query to have. Imagine that one session manually
sets a timeout to 1ms and executes a query normally taking minutes a few
thousand times. The stats wouldn't make a lick of sense anymore.
One way to address this at least partially would be to add a counter for
initiated queries and a counter for completed queries (the current
one). If all the rest of the counters are left the same the issue from
above isn't there, and you'd not even need an exception handler to
update counters.
- Andres
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs