Re: [External] RE: Estimate time without running the query
От | Adrian Klaver |
---|---|
Тема | Re: [External] RE: Estimate time without running the query |
Дата | |
Msg-id | 1ddc4fab-c89c-4c4e-c252-8f1179d51dcc@aklaver.com обсуждение исходный текст |
Ответ на | Re: [External] RE: Estimate time without running the query (Neto pr <netoprbr9@gmail.com>) |
Список | pgsql-general |
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@gmail.com <mailto:david.g.johnston@gmail.com>> escreveu: > > On Thu, Sep 13, 2018 at 3:30 PM, Neto pr <netoprbr9@gmail.com > <mailto:netoprbr9@gmail.com>>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@aklaver.com
В списке pgsql-general по дате отправления: