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 по дате отправления: