Re: Dynamic result sets from procedures

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Dynamic result sets from procedures
Date: 2017-11-03 17:48:20
Message-ID: f396e049-ee1c-2569-180b-de9d9015bb5c@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/1/17 06:23, Pavel Stehule wrote:
> We need to think about how the \timing option should work in such
> scenarios.  Right now it does

> Has the total time sense  in this case?
>
> should not be total time related to any fetched result?

The \timing option in psql measures from the time you send off the
statement until you get all the results back. I don't see a fundamental
reason to change that if a statement happens to produce multiple
results. The results already come over the write and are processed by
libpq. So the time is already measured. It's just that psql doesn't
print the non-last result sets.

We don't have any way to measure from psql how long each individual
result set took to compose. For that you will need deeper tools like
EXPLAIN ANALYZE and some way to process that data. That is way beyond
what \timing currently does.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-11-03 17:50:28 Re: Dynamic result sets from procedures
Previous Message Peter Eisentraut 2017-11-03 17:42:42 Re: Linking libpq statically to libssl