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,
>
On Mon, 2009-11-30 at 10:50 -0800, Craig James wrote:
> I have a million-row table (two text columns of ~25 characters each plus two
> integers, one of which is PK) that is replaced every week. Since I'm doing
> it on a live system, it's run inside a transaction. This is the only time
> the ta
I have a million-row table (two text columns of ~25 characters each plus two
integers, one of which is PK) that is replaced every week. Since I'm doing it
on a live system, it's run inside a transaction. This is the only time the
table is modified; all other access is read-only.
I wanted to
Hi everybody,
I have an java application like this:
while ( true ) {
Thread.sleep( 1000 ) // sleeps 1 second
SELECT field1
FROM TABLE1
WHERE field2 = '10'
if ( field1 != null ) {
BEGIN;
processSomething( field1 );
UPDATE TABLE1
SET
Ron Mayer wrote:
> Bruce Momjian wrote:
> > Greg Smith wrote:
> >> Bruce Momjian wrote:
> >>> I thought our only problem was testing the I/O subsystem --- I never
> >>> suspected the file system might lie too. That email indicates that a
> >>> large percentage of our install base is running on unr
Bruce Momjian wrote:
> Greg Smith wrote:
>> Bruce Momjian wrote:
>>> I thought our only problem was testing the I/O subsystem --- I never
>>> suspected the file system might lie too. That email indicates that a
>>> large percentage of our install base is running on unreliable file
>>> systems ---
Bruce Momjian wrote:
>> For example, ext3 fsync() will issue write barrier commands
>> if the inode was modified; but not if the inode wasn't.
>>
>> See test program here:
>> http://www.mail-archive.com/linux-ker...@vger.kernel.org/msg272253.html
>> and read two paragraphs further to see how touchi
On Fri, Nov 27, 2009 at 4:47 PM, Faheem Mitha wrote:
If not, you might want to look at some way of pre-marking the
non-duplicate rows so that you don't have to recompute that each time.
>>>
>>> What are the options re pre-marking?
>>
>> Well, what I usually do is - if I'm going to do the
Ing . Marcos Luís Ortíz Valmaseda wrote:
Ivan Voras escribió:
Ing . Marcos Luís Ortíz Valmaseda wrote:
Regards to all the list.
ZFS, the new filesystem developed by the Solaris Development team and
ported to FreeBSD too, have many advantages that can do that all
sysadmins are questioned
abou
Ivan Voras escribió:
Ing . Marcos Luís Ortíz Valmaseda wrote:
Regards to all the list.
ZFS, the new filesystem developed by the Solaris Development team and
ported to FreeBSD too, have many advantages that can do that all
sysadmins are questioned
about if it is a good filesystem to the Postgr
Greg Smith wrote:
> Bruce Momjian wrote:
> > I thought our only problem was testing the I/O subsystem --- I never
> > suspected the file system might lie too. That email indicates that a
> > large percentage of our install base is running on unreliable file
> > systems --- why have I not heard abo
Ing . Marcos Luís Ortíz Valmaseda wrote:
Regards to all the list.
ZFS, the new filesystem developed by the Solaris Development team and
ported to FreeBSD too, have many advantages that can do that all
sysadmins are questioned
about if it is a good filesystem to the PostgreSQL installation.
Any
14 matches
Mail list logo
