pg_stat_statements with fetch

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: pg_stat_statements with fetch
Date: 2017-05-19 23:04:36
Message-ID: CAMkU=1wW5vX5+PCVAPrmHH6589h-1dLKYqwrwCp18obpTZFUbA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

I'm spoiled by using pg_stat_statements to find the hotspot queries which
could use some attention.

But with some recent work, all of the hotspots are of the form "FETCH 1000
FROM c3". The vast majority of the queries return less than 1000 rows, so
only one fetch is issued per execution.

Is there an automated way to trace these back to the parent query, without
having to strong-arm the driving application into changing its cursor-using
ways?

pg_stat_statements v1.4 and postgresql v9.6 (or 10beta1, if it makes a
difference)

Sometimes you can catch the DECLARE also being in pg_stat_statements, but
it is not a sure thing and there is some risk the name got freed and reused.

log_min_duration_statement has the same issue.

Cheers,

Jeff

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Zac Goldstein 2017-05-20 23:33:16 Index not being used on composite type for particular query
Previous Message Tom Lane 2017-05-19 16:09:58 Re: GIN index not used if created in the same transaction as query