Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.databases > #594
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Newsgroups | comp.lang.java.databases |
| Subject | Re: Query performance |
| Date | 2013-04-15 22:05 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <kkhtik$66s$2@dont-email.me> (permalink) |
| References | <02ee34f7-b22a-4704-b504-4b24920092a3@googlegroups.com> <v8jom8hrvb887ep7fr3teuljqiebqtpd0b@4ax.com> |
On Mon, 15 Apr 2013 11:58:59 -0700, Roedy Green wrote: > On Fri, 5 Apr 2013 04:16:56 -0700 (PDT), thomas.lehmann@adtech.com > wrote, quoted or indirectly quoted someone who said : > > >>Does somebody has an idea? > > If you have a performance problem, first thing is to use a prepared > statement. > > Also give it a chance to "warm up" fill caches, glean data to optimise > etc. > > Next, analyse it the way we did back in the 1970s, figuring out how the > head moves on the typical transaction. > That isn't usually the gotcha in a modern database: the usual problem is that the DBA designed the database physical schema (by that I mean the way each table is stored and the indexes used to support prime keys and other access paths) from the overall system design but the developers forgot to tell him about the access paths they actually use. They then compound the problem by using very small datasets during development with the result that during development the DB runs like greased lightning because the entire database fits in RAM. Then, when the system goes live and volumes get closer to the design volumes they wonder why everything starts to run like molasses. It gets even worse if an SQL neophyte uses an automatic SQL generator to produce the SQL and never looks at the result: some of the code these things can spit out is braindead stuff. One case I was asked to look at one Friday evening was taking 25 seconds to insert new account details with a mere 25,000 accounts in the system. PowerBuilder SQL on a Sybase database was the culprit: a 5 year old could have written better SQL. Once I'd seen the query and schema it was a straight forward job to manually rewrite and retest the query. This put the performance back to the expected few milliseconds per transaction. And I still got to the pub on time. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
Back to comp.lang.java.databases | Previous | Next — Previous in thread | Next in thread | Find similar
Query performance thomas.lehmann@adtech.com - 2013-04-05 04:16 -0700
Re: Query performance "John B. Matthews" <nospam@nospam.invalid> - 2013-04-05 09:30 -0400
Re: Query performance David Kerber <dkerber@WarrenRogersAssociates.invalid> - 2013-04-11 08:18 -0400
Re: Query performance Roedy Green <see_website@mindprod.com.invalid> - 2013-04-15 11:58 -0700
Re: Query performance Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-15 22:05 +0000
Re: Query performance Arne Vajhøj <arne@vajhoej.dk> - 2013-04-15 21:14 -0400
Re: Query performance Arne Vajhøj <arne@vajhoej.dk> - 2013-04-15 21:12 -0400
Re: Query performance Lew <lewbloch@gmail.com> - 2013-04-15 19:01 -0700
Re: Query performance Martin Gregorie <martin@address-in-sig.invalid> - 2013-04-15 21:39 +0000
Re: Query performance Arne Vajhøj <arne@vajhoej.dk> - 2013-04-15 21:18 -0400
Re: Query performance Harry Tuttle <SOZRBLNTLEEE@spammotel.com> - 2013-04-16 14:59 +0200
csiph-web