On Tue, Oct 11, 2016 at 3:16 PM, Francisco Olarte <folarte@xxxxxxxxxxxxxx> wrote:
Rakesh:
On Tue, Oct 11, 2016 at 9:00 PM, Rakesh Kumar
<rakeshkumar464@xxxxxxxxxxx> wrote:
>>Cores do not help, postgres is single-threaded. RAM MAY help, but I
> I hope this is no longer true from 9.6 for those queries where PG can use parallelism.
It does, AFAIK, but for queries, not AFAIK for this kind of data
moving ops ( and I doubt it will, as presently you can easily saturate
the channels with a single core for that kind of simple ops, and
normally if you want to optimize this kind of op is better to target
concurrency ( table can be used while moving ) than pure speed .
Francisco Olarte.
>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.
And if there are transactions occurring against that table, there is no telling how long it will take. Since we
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.
--
Melvin Davidson
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.![]()
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.
