Re: debugging handle exhaustion and 15 min/ 5mil row delete

Поиск
Список
Период
Сортировка
От Marcos Ortiz
Тема Re: debugging handle exhaustion and 15 min/ 5mil row delete
Дата
Msg-id 4BE41432.5000203@uci.cu
обсуждение исходный текст
Ответ на Re: debugging handle exhaustion and 15 min/ 5mil row delete  (Mark Stosberg <mark@summersault.com>)
Список 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 по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: partioning tips?
Следующее
От: Craig James
Дата:
Сообщение: Dell Perc HX00 RAID controllers: What's inside?