Perhaps making your select be explicitely part of a read-only
transaction rather than letting java make use of an implicit
transaction (which may be in auto commit mode)
On 11/30/09, Waldomiro wrote:
> Hi everybody,
>
> I have an java application like this:
>
> while ( true ) {
> Thread.slee
> -Mensaje original-
> De: Waldomiro
>
> I´m using PostgreSQL 8.1,
Sorry, log_checkpoints isn't supported till 8.3
> and my settings are:
>
> checkpoint_segments=50
> checkpoint_timeout=300
> checkpoint_warning=30
> commit_delay=0
> commit_siblings=5
> archive_command= cp -i %p/BACK
I´m using PostgreSQL 8.1, and my settings are:
checkpoint_segments=50
checkpoint_timeout=300
checkpoint_warning=30
commit_delay=0
commit_siblings=5
archive_command= cp -i %p/BACKUP/LOGS/%f
autovacuum=off
bgwriter_all_maxpages=5
bgwriter_all_percent=0.333
bgwriter_delay=200
bgwriter_lru_maxpage
I´m using PostgreSQL 8.1. There is a way to see that?
Waldomiro
Greg Smith escreveu:
Waldomiro wrote:
Is It possible the checkpoint is doing that? Or the archiving? How
can I see?
If you're using PostgreSQL 8.3 or later, you can turn on
log_checkpoints and you'll get a note when each checkpoi
Waldomiro wrote:
Is It possible the checkpoint is doing that? Or the archiving? How can
I see?
If you're using PostgreSQL 8.3 or later, you can turn on log_checkpoints
and you'll get a note when each checkpoint finishes. The parts that are
more likely to slow the server down are right at the e
On Mon, Nov 30, 2009 at 8:02 PM, Waldomiro wrote:
> Its not a vaccum needed, becouse I do a TRUNCATE every night.
But you're updating each row 20 times a day - you could very well need a vacuum.
> Is It possible the checkpoint is doing that? Or the archiving? How can I
> see?
It seems likely to
> -Mensaje original-
> De: pgsql-performance-ow...@postgresql.org
> [mailto:pgsql-performance-ow...@postgresql.org] En nombre de Waldomiro
> Enviado el: Lunes, 30 de Noviembre de 2009 22:03
> Para: pgsql-performance@postgresql.org
> Asunto: [PERFORM] Server Freezing
>
> Hi everybody,
>
