Re: slow update but have an index - Mailing list pgsql-general
From | Jeff Eckermann |
---|---|
Subject | Re: slow update but have an index |
Date | |
Msg-id | 019a01c1272b$f9da8810$279c10ac@INTERNAL Whole thread Raw |
In response to | slow update but have an index (Feite Brekeveld <feite.brekeveld@osiris-it.nl>) |
List | pgsql-general |
My experience with bulk inserts/updates is that indexes cause a major performance hit, because they have to be rebuilt after every insert/update. Also, each insert/update is wrapped in a transaction by default, so there is transaction overhead for each one too. Wrapping all of the statements in a BEGIN; .... COMMIT; would probably solve both of these problems. Dropping and recreating the index might help too. Results will vary according to the situation. ----- Original Message ----- From: "Feite Brekeveld" <feite.brekeveld@osiris-it.nl> To: "Martijn van Oosterhout" <kleptog@svana.org> Cc: <pgsql-general@postgresql.org> Sent: Friday, August 17, 2001 7:18 AM Subject: Re: [GENERAL] slow update but have an index > Martijn van Oosterhout wrote: > > > On Fri, Aug 17, 2001 at 01:40:32PM +0200, Feite Brekeveld wrote: > > > > Well, an index speeds it up, but that times 80,000 will still take a while. > > > > Is there any trickery or will this work? > > > > > > > > update accounting set status = 'C'; > > > > > > > > If so, that will be much faster. > > > > > > No that will not work, because they other 6000 need not to be changed. Of > > > course I could update the this way and change the other 6000 back to their > > > original status, but the query I issued is so slow that I think something is > > > wrong. > > > > Well, there's a bit of an issue here. Each time you do an insert, the table > > gets larger, the index gets larger, etc. Disk accesses everywhere. If you > > can do it one query then the sequential is much friendlier to disk caches > > and the performance will be much more consistant. > > > > Can you codify in an SQL query how you decide which records to change. I've > > found the best way to improve performance is to minimise the number of > > queries, letting the database do the maximum optimisation possible. > > > > hacked it with perl into several > > update ... where seqno between x and y statements. > > That went smoothly. > > > > > > > -- > > Martijn van Oosterhout <kleptog@svana.org> > > http://svana.org/kleptog/ > > > It would be nice if someone came up with a certification system that > > > actually separated those who can barely regurgitate what they crammed over > > > the last few weeks from those who command secret ninja networking powers. > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > > -- > Feite Brekeveld > feite.brekeveld@osiris-it.nl > http://www.osiris-it.nl > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > >
pgsql-general by date: