Le 11/10/2017 à 16:11, Purav Chovatia a écrit :
Thanks.
We looked at pg_stat_statements and we see execution count & total
time taken. But that still does not help me to identify why is it slow
or what is taking time or where is the wait.
btw, does pg_stat_statements add considerable overhe
Hi Dinesh,
Le 07/06/2017 à 14:48, Andreas Kretschmer a écrit :
Am 07.06.2017 um 13:33 schrieb Dinesh Chandra 12108:
Dear Expert,
Is there any way to rollback table data in PostgreSQL?
if you are looking for somewhat similar to flashback in oracle the
answer is no.
Well, if this is what
Hi Ravi,
We, at Dalibo, are contributing to the postgres community mostly through
open source administration tools development.
Among them :
- pgBadger, from Gilles Darold, extracts a lot of data from the postgres
logs and restitutes them via a web interface
(https://github.com/dalibo/pgbadg
Le 21/09/2016 à 23:42, Jim Nasby a écrit :
On 9/12/16 1:05 PM, phb07 wrote:
The drawback is the overhead of this added ANALYZE statement. With a
heavy processing like in this test case, it is worth to be done. But for
common cases, it's a little bit expensive.
You could always look a
Thanks, Tom, for this quick answer.
Le 12/09/2016 à 16:41, Tom Lane a écrit :
phb07 writes:
The performance issue, encountered in very specific situations, is the
time needed to cancel a significant number of insertions.
I have build a simple test case that reproduces the problem without the
Hi all,
One of my customer has reported to me a performance problem when using
the E-Maj extension.
It is a tool that allows to log updates performed on application tables,
with the capability to cancel them.
It is based on classic triggers with a log table associated to each
application table.
Hi all,
At Bull company, we want to answer a call for tender from a large
company. And we are asked for information about PostgreSQL performance
under AIX on Power 7 servers.
By chance, has someone some data about this ?
Has someone performed a benchmark using AIX quite recently ?
Are there
Royce Ausburn a écrit :
All of the queries on this table are reporting on a single collection, so ideally a collection's data would all be stored in the same part of the disk... or at least clumped together. This can be achieved using "cluster", however as far as I know there's no automated, non
Dimitri a écrit :
It's probably one of the cases when having HINTS in PostgreSQL may be
very helpful..
SELECT /*+ enable_nestloop=off */ ... FROM ...
will just fix this query without impacting other queries and without
adding any additional instructions into the application code..
So, why the
