From: | Neto pr <netoprbr9(at)gmail(dot)com> |
---|---|
To: | david(dot)g(dot)johnston(at)gmail(dot)com |
Cc: | vjain(at)opentable(dot)com, johnescm(at)hotmail(dot)com, PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: [External] RE: Estimate time without running the query |
Date: | 2018-09-13 23:55:24 |
Message-ID: | CA+TZvY+0E9jCGo0NuMykBQozwBSYNoZb6Pp5efed5vkKJvStSw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Em qui, 13 de set de 2018 às 19:53, David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> escreveu:
> On Thu, Sep 13, 2018 at 3:30 PM, Neto pr <netoprbr9(at)gmail(dot)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?
> David J.
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-09-14 00:21:18 | Re: Behaviour when autovacuum is canceled |
Previous Message | Martín Fernández | 2018-09-13 23:14:41 | Re: Behaviour when autovacuum is canceled |