Re: BUG #16054: Slowest individual queries

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: PG Bug reporting form <noreply(at)postgresql(dot)org>
Cc: pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>, a(dot)gowri82(at)gmail(dot)com
Subject: Re: BUG #16054: Slowest individual queries
Date: 2019-10-15 00:35:16
Message-ID: CAMkU=1w5PoaTJCJ15G7p+eSjQwrDb2ugEDvQXBHvEmF5J8Z84A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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

> The following bug has been logged on the website:
>
> Bug reference: 16054
> Logged by: Gowri Sankar
> Email address: a(dot)gowri82(at)gmail(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Justin Pryzby 2019-10-15 04:41:18 Re: BUG #16045: vacuum_db crash and illegal memory alloc after pg_upgrade from PG11 to PG12
Previous Message Tomas Vondra 2019-10-15 00:18:17 Re: BUG #16045: vacuum_db crash and illegal memory alloc after pg_upgrade from PG11 to PG12