bin@rhesus.primate.wisc.edu (Brain in Neutral) (10/13/88)
Why is RTI Ingres docopy such an abysmal loser in version 5 as compared to version 3? I thought perhaps it was just slow writing to files if the format list was given, but it's not much better doing a bulk copy. Is there something I can tweak to speed it up? Paul DuBois dubois@primate.wisc.edu rhesus!dubois bin@primate.wisc.edu rhesus!bin
steve@violet.berkeley.edu (Steve Goldfield) (10/15/88)
In article <412@rhesus.primate.wisc.edu> bin@rhesus.primate.wisc.edu (Brain in Neutral) writes:
#>Why is RTI Ingres docopy such an abysmal loser in version 5 as
#>compared to version 3? I thought perhaps it was just slow writing
#>to files if the format list was given, but it's not much better
#>doing a bulk copy. Is there something I can tweak to speed it up?
#>
#>Paul DuBois
#>dubois@primate.wisc.edu rhesus!dubois
#>bin@primate.wisc.edu rhesus!bin
We've had the same experience here. Our Ingres cpu charges
are exorbitantly high (on a Vax 8650). I got a detailed list
of charges and found that docopy was one big offender.
Quels on multiple tables was the other. The strange thing
is that running reports is very cheap. So you could presumably
generate a text file with a report for $.15 or so or copy to
a text file for about $15. I haven't tried doing both on the
same file, though.
Steve Goldfieldjkrueger@daitc.daitc.mil (Jonathan Krueger) (10/15/88)
In article <412@rhesus.primate.wisc.edu> bin@rhesus.primate.wisc.edu (Brain in Neutral) writes: >Why is RTI Ingres docopy such an abysmal loser... >Is there something I can tweak to speed it up? Partial answer: try the text(0)delim output format. Contrary to the documentation (version 5.0 Quel reference manual, section 2.5.3.2), this format omits trailing spaces. (The document says this works only for text datatypes). I recommend text(0)nl as safest. Yes, it's tedious to maintain dump scripts written this way. I may write a script generator: anyone interested? Why this is only a partial answer: it's still slow. -- Jon
saks@manta.NOSC.MIL (Joel A. Saks) (10/15/88)
In article <412@rhesus.primate.wisc.edu> bin@rhesus.primate.wisc.edu (Brain in Neutral) writes: >Why is RTI Ingres docopy such an abysmal loser in version 5 as >compared to version 3? We encountered the docopy problem when we first installed INGRES 5.0 under BSD UNIX (then 4.2, now 4.3). RT acknowledged the problem and sent us a fixed version of docopy, which works as quickly as it had in previous versions. If you are running BSD UNIX, you probably do not want to wait for the next INGRES maintenance release, which has been due out for quite some time now. I suggest you call Tech Support at RT to have them send you the docopy fix on a tape or via uucp. Joel Saks (saks@nosc.mil) Computer Sciences Corp., San Diego (619) 225-8401
johan@cwi.nl (Johan Wolleswinkel) (10/15/88)
In article <412@rhesus.primate.wisc.edu> bin@rhesus.primate.wisc.edu (Brain in Neutral) writes: >Why is RTI Ingres docopy such an abysmal loser in version 5 as >compared to version 3? I thought perhaps it was just slow writing >to files if the format list was given, but it's not much better >doing a bulk copy. Is there something I can tweak to speed it up? > >Paul DuBois >dubois@primate.wisc.edu rhesus!dubois >bin@primate.wisc.edu rhesus!bin We, at the CWI, in Amsterdam, The Netherlands, got the same feeling when we upgraded from V3 to V5, in february 1987, running on a Dec VAX-750 under Unix BSD 4.3. To quantify this feeling I did some experiments copying some medium-sized table in one of our databases. The table contained 6515 rows of c1,i4,i4,i1,i2,i4,text(255), the mean actual width of the last column was 26; every column was copied with format "c0@", the last column with c0nl, and in a second part of the experiment the c0 was replaced by text(0), which resulted in filesizes of resp. 2.0 MB and 275 kB. We showed the (horrible) results to RTI and they supplied us with another version of the `docopy'- binary, which couldn't be used because of some internal error. The slow-down was caused by extended checking (the only example supplied was checking by row available disk-space to write that single row). It turned out, that the V3- binary could be used within an otherwise V5- system, which we did, until we got another release (V5.0.4, prepared for Mt Xinu 4.3, may 1988). Unfortunately there were some problems using this version under BSD 4.3, so we only used it for development tests. Last week we got a BSD 4.3 version of release V5.0.4; the results for the copy- experiment were rather pleasing: Summary: Version size cpu-time docopy c0 text(0) binary backend docopy backend docopy 5.0/01 (vax.u42/02) + docopy(V3) 8 192 57 102 88 14 5.0/01 (vax.u42/02) 23 552 59 8140 - 5.0/01' 10 240 * * 5.0/04 (vax.u43/01)MtX 50 176 56 11 85 2 5.0/04 (vax.u43/02)BSD 32 768 58 11 93 2 Conclusion: Get a new release from your RTI- office; in the meantime use the `docopy'- binary from V3. Remarks: 1. `docopy' is not only used by Quel or SQL for a `copy' stmt, but also by other products for copying tables to files e.g. by `abf'. 2. I would be interested in sharing other experiences with the Ingres- products. 3. The figures specified for the backends may vary by more than 10 percent, depending upon the load of the system. -- Johan -- Johan Wolleswinkel CWI, Postbus 4079, 1009 AB Amsterdam, Kruislaan 413, The Netherlands Phone: +31 20 5924050 Telex: 12571 (mactr nl) UUCP: johan@cwi.nl or ...{seismo,philabs,decvax}!mcvax!johan
bin@rhesus.primate.wisc.edu (Brain in Neutral) (10/19/88)
In article <412@rhesus.primate.wisc.edu>, bin@rhesus.primate.wisc.edu (Brain in Neutral) writes: > Why is RTI Ingres docopy such an abysmal loser in version 5 as > compared to version 3? I thought perhaps it was just slow writing > to files if the format list was given, but it's not much better > doing a bulk copy. Is there something I can tweak to speed it up? I received information from both BSD Unix and Sun sites that they had the same problem and that contacting RTI tech support resulted in a fixed version. This appears to have been the problem for me as well. I just received a uuencoded fixed version in my email. On one of my queries that was a real dog, here are the results of the docopy phase: old docopy: 481.62 seconds new docopy: 1.93 seconds A rather dramatic improvement. I'm very pleased. Thank you, RTI tech support. Yours, Paul DuBois dubois@primate.wisc.edu rhesus!dubois bin@primate.wisc.edu rhesus!bin