2008/6/26 Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>:
> 2008/6/26 jay <jackem(dot)mojx(at)alibaba-inc(dot)com>:
>> If we can do commit very 1000 row per round, it may resolve the
>> 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.
In a way that's what pg_bulkloader does.
In response to
pgsql-performance by date
|Next:||From: Scott Marlowe||Date: 2008-06-26 16:02:31|
|Subject: Re: [PERFORM] 答复: [PERFORM] Postgresql update op is very very slow|
|Previous:||From: Tom Lane||Date: 2008-06-26 15:04:21|
|Subject: Re: 答复: [PERFORM] Postgresql update op is very very slow|