Re: debugging handle exhaustion and 15 min/ 5mil row delete - Mailing list pgsql-performance

From Marcos Ortiz
Subject Re: debugging handle exhaustion and 15 min/ 5mil row delete
Date
Msg-id 4BE41432.5000203@uci.cu
Whole thread Raw
In response to Re: debugging handle exhaustion and 15 min/ 5mil row delete  (Mark Stosberg <mark@summersault.com>)
List pgsql-performance
El 07/05/2010 16:10, Mark Stosberg escribió:
>
>> You can use TRUNCATE instead DELETE. TRUNCATE is more efficient and
>> faster that DELETE.
>>
> Thanks for the suggestion. However, TRUNCATE is not compatible with
> Slony, and we also have some rows which remain in table.
>
>
>> Now, we need more information about your system to give you a certain
>> solution:
>> Are you using a RAID controller for you data?
>>
> Yes.
>
>
>> Do you have separated the xlog directory from the data directory?
>>
> No.
>
>
>> Which is your Operating System?
>>
> FreeBSD.
>
>
>> Which is you architecture?
>>
> i386.
>
> Thanks for the feedback. I'm going to try batching the deletes for now,
> which is approach was worked well for some of our other long-running
> deletes.
>
>      Mark
>
>
Have you valorated to use a 64 bits version of FreeBSD for that?
The 64 bits OS can help you very much on large databases because yo can
use actually all available RAM that you have on the server.

Many experts on this list recommende to separate the xlog directory on a
RAID 1 configuration and the data directory on RAID 10 to obtain a
better performance.
The filesystems are very diverse, but I ´ve seen that ZFS is very useful
on these cases.

Which version of Slony-I are you using?

Regards

pgsql-performance by date:

Previous
From: Josh Berkus
Date:
Subject: Re: partioning tips?
Next
From: Craig James
Date:
Subject: Dell Perc HX00 RAID controllers: What's inside?