its, so its all on the
> CPU.
You could profile the PostgreSQL server while it is executing the
workload,
see for example https://wiki.postgresql.org/wiki/Profiling_with_perf
That way you could see where the time is spent.
PL/pgSQL is not optimized for performance like PL/SQL.
Yours,
Laurenz Al
ing transaction that blocks the
ACCESS EXCLUSIVE lock required. It could also be a prepared
transaction.
Yours,
Laurenz Albe
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
t is not very performant
for bulk update operations.
If performance is the main objective, use export/import.
Yours,
Laurenz Albe
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
nijam J wrote:
> our server is getting too slow again and again
Use "vmstat 1" and "iostat -mNx 1" to see if you are
running out of memory, CPU capacity or I/O bandwith.
Figure out if the slowness is due to slow queries or
an overloaded system.
Yours,
Laurenz Al
L is to *not* have
query hints, and for a number of good reasons, this is far from being
an unanimous decision. The scales may tip at some point, though I
personally hope that this point is not too close.
Yours,
Laurenz Albe
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
posals that aim at fixing the selectivity
estimates, e.g. "multiply your estimate for this join by three".
> In my Aqua
> Data Studio, if I put the set statement before the select statement, the
> combined statement doesn't return any results. May be I am doing
>
