BUG #16054: Slowest individual queries

On Mon, Oct 14, 2019 at 02:24:10AM +0000, PG Bug reporting form wrote:

The following bug has been logged on the website:

Bug reference: 16054
Logged by: Gowri Sankar
Email address: a.gowri82@gmail.com
PostgreSQL version: 10.9
Operating system: Amazon Linux
Description:

Hi
We can see from below similar queries are frequently reported as Slowest
individual queries. During the same time period high Read IOPS .Please let
me know what is the cause for this fetch statements. Let me know as well
regards this more information.

FETCH 100 FROM c2;
FETCH 100 FROM c6;
FETCH 100 FROM c2;

This is very clearly not a bug report, but a question about slow query.
And a woefully incomplete one, because we have no idea what the query
does, whether it's the cause or victim of high I/O usage, etc.

Please read https://wiki.postgresql.org/wiki/Slow_Query_Questions and
then post a question to either pgsql-general or pgsql-performance with
more detailed info.

regars

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Sun, Oct 13, 2019 at 10:28 PM PG Bug reporting form <
noreply@postgresql.org> wrote:

The following bug has been logged on the website:

Bug reference: 16054
Logged by: Gowri Sankar
Email address: a.gowri82@gmail.com
PostgreSQL version: 10.9
Operating system: Amazon Linux
Description:

Hi
We can see from below similar queries are frequently reported as Slowest
individual queries. During the same time period high Read IOPS .Please let
me know what is the cause for this fetch statements. Let me know as well
regards this more information.

FETCH 100 FROM c2;
FETCH 100 FROM c6;
FETCH 100 FROM c2;

Someone has declared a cursor, and is fetching from it. When I see these
types of queries, they are usually coming from postgres_fdw.

It is annoying that it shows you the FETCH statement itself, and not the
original statement. If you can use auto_explain, which will show you the
original statement.

Cheers,

Jeff