Re: My DB has has 5TB, many operations are very slow (on Google Cloud Compute) - Mailing list pgsql-general

From Francisco Olarte
Subject Re: My DB has has 5TB, many operations are very slow (on Google Cloud Compute)
Date
Msg-id CA+bJJbxMJ1UNqnpnA0LYaaCoGgdGweuCwaQExy0QoZeZwoGqyg@mail.gmail.com
Whole thread Raw
In response to Re: My DB has has 5TB, many operations are very slow (on Google Cloud Compute)  (Melvin Davidson <melvin6925@gmail.com>)
List pgsql-general
Melvin:

On Tue, Oct 11, 2016 at 9:50 PM, Melvin Davidson <melvin6925@gmail.com> wrote:
> >Requiring and exclusive table lock does not imply slownes. Just try
> >'lock table x in exclusive mode' on an idle system. Pretty fast.
> Sure on an idle system, you will get a table lock right away, but OP's statements imply a large busy system.
May be OP, but not PP ( previous poster ).

Had you not merged two replies in one and pruned the context too much,
you could have read yourself ( not too sure, maybe I have my local
copies of mail borked and it was other person ) saying, just before
this:

> FYI, moving between tablespaces requires an exclusive table lock, so it's naturally going to be slow.

English is not my mother tongue, but this seems to imply slowness
being blamed on the table lock, maybe someone more knowledgeable in
the finer details of english language can explain it for to me if it
is not the case.


> And if there are transactions occurring against that table, there is no telling how long it will take.
> Since we do not have enough specific info, I stand by my statement.

I would not expect less. I do not remember where the OP stated a busy
system, but anyway the lock is going to execute fast and but with a
long delay, and counting the time form the issuing of the command to
the time of end is a perfectly reasonable way to do it.

Anyway, ok, exclusive locks cause the slownes.

Francisco Olarte.


pgsql-general by date:

Previous
From: "Martijn Tonies \(Upscene Productions\)"
Date:
Subject: Re: ANN: Upscene releases Database Workbench 5.2.4
Next
From: Adrian Klaver
Date:
Subject: Re: confusion about user paring with pg_hba and pg_ident