explain analyze would *run* the query and it can be dangerous if it is a DML
statement like insert/update/delete
If you still want to go with explain analyze,
You can do
begin;
explain analyze ;
rollback;
thanks,
Vijay
From: Johnes Castro
Date: Friday, September 14, 2018 at 3:12 AM
To:
On Thu, Sep 13, 2018 at 3:45 PM, Martín Fernández
wrote:
> From what I could understand (that can be totally wrong), the vacuum
> process is split in multiple small transactions. If the autovacuum is
> canceled, could it be possible that only the latest transaction work be
> lost
>
>From the
Hi,
I'm using AWS RDS Postgres (9.6.6) and have run into very slow shutdowns
(10+ minutes) a few times when making database modifications (e.g. reboot,
changing instance size, etc.). Other times, it shuts down quickly (1
minute or so). I have not been able to figure out why sometimes it takes a
Yeah, I figured that. Unfortunately, every time it happens, I open a
support ticket with them, but they always just tell me that this is normal
behavior for postgres. Whether it's "normal" or not, I really would like
to get my db to shut down faster, and their suggestion of manually shutting
David,
Thanks a lot for the quick reply.
I clearly misunderstood the references in the code.
Best,
Martín
On Thu, Sep 13th, 2018 at 7:55 PM, "David G. Johnston"
wrote:
>
>
> On Thu, Sep 13, 2018 at 3:45 PM, Martín Fernández < fmarti...@gmail.com >
> wrote:
>
>
>> From what I could
Hi netoprbr,
Use a command explain analyse.
Best Regards.
Johnes Castro
De: Neto pr
Enviado: quinta-feira, 13 de setembro de 2018 19:38
Para: PostgreSQL General
Assunto: Estimate time without running the query
Dear all,
Only a doubt.
The Explain command only
Hello,
I'm working on a high volume transaction database and we are starting to tune
our autovacuum setting to improve our vacuuming performance.
Once thing that we know about autovacuum is that is can be automatically
canceled if a dependent transaction is blocked by the autovacuum
Dear all,
Only a doubt.
The Explain command only estimates the cost of execution of a
query, and does not estimate time for execution.
I would like know if exists some way to estimate the time, without running
the query?
Best Regards
[]`s Neto
Em qui, 13 de set de 2018 às 18:49, Vijaykumar Jain
escreveu:
> explain analyze would *run* the query and it can be dangerous if it is a
> DML statement like insert/update/delete
>
>
>
> If you still want to go with explain analyze,
>
> You can do
>
>
>
> begin;
>
> explain analyze ;
>
>
On Thu, Sep 13, 2018 at 3:30 PM, Neto pr wrote:
> The problem is that using the explain analyze 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
On 09/13/2018 03:04 PM, Chris Williams wrote:
Hi,
I'm using AWS RDS Postgres (9.6.6) and have run into very slow
shutdowns (10+ minutes) a few times when making database modifications
(e.g. reboot, changing instance size, etc.). Other times, it shuts
down quickly (1 minute or so). I have
On 9/13/18 3:59 PM, Chris Williams wrote:
Yeah, I figured that. Unfortunately, every time it happens, I open a
support ticket with them, but they always just tell me that this is
normal behavior for postgres. Whether it's "normal" or not, I really
would like to get my db to shut down faster,
David,
Your last comment applies for cleaning up indexes as well ? We performed a
simple test in our production database to understand behaviour and we got a
result that surprised us based on your last comment.
We basically started a VACUUM on a given table, waited for one index to process
Tom,
Thanks for the detailed explanation. I can start mapping your explanation with
the source code I've been reading :)
We are in the process of tuning our autovacuum settings (on some tables) and
stop relying on crontabs that are performing manual vacuums.
By performing this changes we are
Em qui, 13 de set de 2018 às 19:53, David G. Johnston <
david.g.johns...@gmail.com> escreveu:
> On Thu, Sep 13, 2018 at 3:30 PM, Neto pr wrote:
>
>> The problem is that using the explain analyze I have to wait for
>> the query to execute.
>> I would like to estimate the time without having to
=?UTF-8?q?Mart=C3=ADn_Fern=C3=A1ndez?= writes:
> We basically started a VACUUM on a given table, waited for one index to
> process (captured cleaned rows count) and cancel the VACUUM. When we run
> another VACUUM on the same table the dead rows removed from the first index
> was a number
The below query basically gives the result by maintaining the order of the
sizes in the list.
explain analyze select
"price_levels"."name",
"price_levels"."size"
from
"price_levels"
join unnest(array['M',
'L',
'XL',
'2XL',
'3XL',
> On Sep 13, 2018, at 12:17 PM, Arup Rakshit wrote:
>
> The below query basically gives the result by maintaining the order of the
> sizes in the list.
>
> explain analyze select
> "price_levels"."name",
> "price_levels"."size"
> from
> "price_levels"
> join
18 matches
Mail list logo
