From: | Satalabaha Postgres <satalabaha(dot)postgres(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-admin(at)lists(dot)postgresql(dot)org |
Subject: | Re: Finding query execution time using \timing and EXPLAIN ANALYZE.. |
Date: | 2022-11-22 06:26:59 |
Message-ID: | CAJ_W8naE5OFjc59-HxXrD-ZkG1UPwCGNX7z1-yscyH+_U58njQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Hello Tom,
Thanks for the response and making things clear.
BTW this test case was from a RDS aurora postgres cluster. It is just a
dummy table that I created. And yes after repeated executions for both
\timing and explain ... , I get the same result.
Thanks,
Satalabaha
On Mon, 21 Nov 2022 at 20:24, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Satalabaha Postgres <satalabaha(dot)postgres(at)gmail(dot)com> writes:
> > I was trying to get elapsed time for the sql using the \timing command in
> > psql as well as EXPLAIN ANALYZE.. I see both the commands reporting
> > different elapsed time. And this is after repeated execution of the same
> > query and not the first execution. In this case, which one would be the
> > right execution time for the query.
>
> They're presumably both accurate, but they aren't measuring the same
> thing. psql's \timing reports the end-to-end time from the client's
> perspective. EXPLAIN ANALYZE reports the time for two components
> of the server's processing. So \timing includes all of these:
>
> 1. Transmission of the query across the network to the server
> 2. Parsing and parse analysis of the query
> 3. Rewriting (a/k/a view expansion) of the query
> 4. Planning
> 5. Execution
> 6. Formatting of the query results as text
> 7. Transmission of the results across the network to the client.
>
> while EXPLAIN is only telling you about steps 4 and 5.
>
> Having said that, I'm a bit baffled by the size of the difference.
> This example doesn't look like any of the other steps should take
> very long: it's a short simple query, there doesn't seem to be
> any view involved, and the result is only one row. Unless maybe
> you're using tin-cans-and-string for the network connection?
>
> There are various effects whereby the first execution of a query
> can take longer than repeat executions, but you said you'd
> controlled for that.
>
> Also, how stable are these numbers if you repeat them several
> times? It might be mostly about noise and/or the effects of
> CPU power management. On my Linux box I find that I don't
> get very reproducible numbers for short queries unless I've
> done "sudo cpupower frequency-set --governor performance".
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Massimo Ortensi | 2022-11-22 13:27:09 | Re: Out of memory error during pg_upgrade in big DB with large objects |
Previous Message | Frank Rueter | 2022-11-21 22:16:10 | Re: user credentials rejected by pgAdmin right after new install |