On 9/13/18 4:55 PM, Neto pr wrote:
Em qui, 13 de set de 2018 às 19:53, David G. Johnston
<david.g.johnston@xxxxxxxxx <mailto:david.g.johnston@xxxxxxxxx>> escreveu:
On Thu, Sep 13, 2018 at 3:30 PM, Neto pr <netoprbr9@xxxxxxxxx
<mailto:netoprbr9@xxxxxxxxx>>wrote:
The problem is that using the explain analyze <query> I have to
wait for the query to execute.
I would like to estimate the time without having to wait for the
query execution.
Does anyone know how to estimate the time without waiting for
the query to be executed?
On the machine in question you have to experiment to obtain data to
construct a formula to convert cost to time. Then when using the
function remember that lots of things can play into individual
executions taking more time (and sometimes less too I suspect) such
as locks, caching, physical data locality.
It seems more useful to log actual execution times and look for
trends. If you are writing a query odds are it needs to be run
regardless of how efficient it may be - or used in a relative
comparison to an alternate query.
Okay, David, but does not it have some SQL statement that returns a time
estimate, without having to execute the query?
To get close to a true time you need to run the actual query. An analogy
based on running 10K under the following conditions:
1) Cool day, flat course.
2) Hot day, up a 10% grade.
You can reasonably predict that 1) will yield a faster time then 2),
however you will not know the actual times until you run them.
David J.
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
