You said that " As for processing them in order versus randomly,that's a common problem. "
do you know why? how postgres work in this scenario.
On Wed, Feb 20, 2008 at 3:07 PM, Scott Marlowe <scott.marlowe@xxxxxxxxx> wrote:
On Feb 19, 2008 9:38 PM, hewei <heweiweihe@xxxxxxxxx> wrote:
Assuming that you're updating a non-indexed field, you should really> Hi,Every body;
> I have a table contains 100,000 rows, and has a primary key(int).
> Now ,I need to execute sql command like "update .......... where id=*"(id
> is primary key).
> I expect execute 1200-1600 sqlcommands per second(1200-1600/s).
> In test,when the id increase by degrees in sqlcommands, then I can reach
> the speed(1600/s);
> But in fact , the id in sqlcommands is out of rule, then the speed is
> very slow, just 100/s.
look at migrating to 8.3 if you haven't already. It's performance on
such issues is reportedly much faster than 8.2.
As for processing them in order versus randomly, that's a common
problem. right sizing shared_buffers so that all of the table can fit
in ram might help too. As would a caching RAID controller.
