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',
'4X
> 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 unnest(arr
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
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 es
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: Neto
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
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 no
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 ;
>
> rollba
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 transaction
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 que
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 doc
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
down
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 un
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
(ca
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 wa
=?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 slight
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
18 matches
Mail list logo
