On 9/23/16 12:59 PM, phb07 wrote:
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.
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 at the num
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 at the number of rows affected by a command and
make 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
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
> need of the extension. It just mimics the behaviour.
At least for this e
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.
