Re: [PERFORM] Re: [PERFORM] 答复: [PERFORM] Postgresql update op is very very slow

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: [PERFORM] Re: [PERFORM] 答复: [PERFORM] Postgresql update op is very very slow
Дата
Msg-id dcc563d10806260859m53d57ef5r967066ef2a239fd5@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PERFORM] 答复: [PERFORM] Postgresql update op is very very slow  ("Pavan Deolasee" <pavan.deolasee@gmail.com>)
Список pgsql-performance
2008/6/26 Pavan Deolasee <pavan.deolasee@gmail.com>:
> 2008/6/26 jay <jackem.mojx@alibaba-inc.com>:
>
>>        If we can do commit very 1000 row per round, it may resolve the
>> problem.
>> But  PG not support transaction within function yet?
>>
>
> Yeah, transaction control is not supported inside functions. There are
> some hacks using dblink to do transactions inside functions. You may
> want to check that out.

If you need autonomous transactions.  For most people save points and
catching seem to be a n acceptable form of transaction control.

> I had suggested another hack in the past for very simplistic updates,
> when you are sure that the tuple length does not change between
> updates and you are ready to handle half updated table if there is a
> crash or failure in between. May be for your case, where you are
> updating a single column of the entire table and setting it to some
> default value for all the rows, it may work fine. But please be aware
> of data consistency issues before you try that. And it must be once in
> a lifetime kind of hack.
>
> http://postgresql-in.blogspot.com/2008/04/postgresql-in-place-update.html

In a way that's what pg_bulkloader does.

В списке pgsql-performance по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: 答复: [PERFORM] Postgresql update op is very very slow
Следующее
От: "Scott Marlowe"
Дата:
Сообщение: Re: [PERFORM] 答复: [PERFORM] Postgresql update op is very very slow