home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / database / oracle / 1328 < prev    next >
Encoding:
Internet Message Format  |  1992-08-20  |  1.5 KB
  1. Path: sparky!uunet!oracle!unrepliable!bounce
  2. Newsgroups: comp.databases.oracle
  3. From: kjou@oracle.com (Kathy Jou)
  4. Subject: Re: Oracle table inserts and creations
  5. Message-ID: <1992Aug20.170225.14534@oracle.us.oracle.com>
  6. Sender: Kathy Jou
  7. Nntp-Posting-Host: dvlpyr
  8. Organization: Oracle Corporation
  9. References: <Bt90L3.JGK@monitor.com>
  10. Date: Thu, 20 Aug 1992 17:02:25 GMT
  11. X-Disclaimer: This message was written by an unauthenticated user
  12.               at Oracle Corporation.  The opinions expressed are those
  13.               of the user and not necessarily those of Oracle.
  14. Lines: 20
  15.  
  16. In article <Bt90L3.JGK@monitor.com> bag!howard (Howard Brenner) writes:
  17. >If I know ahead of time that I will be inserting a large amount of data  
  18. >into a table is it more efficient to pre-allocate the space for the table  
  19. >or to let oracle do it when it needs to?
  20.  
  21. One possible gain in efficiency with pre-allocating or pre-extending the table 
  22. before the data is inserted is a very small savings in overhead when the table
  23. grabs another extent during the insert if it was not pre-alloc'd/extended.
  24.  
  25. Make sure you precreate the table's storage parameters to have large enough 
  26. extents to handle the large amount of data, ie you don't want to hit the 
  27. *real* maxextents.  You might notice a slight drop in performance (more 
  28. overhead) if the table has very small extents and the insert will fill up each 
  29. extent with data much faster, spending more time creating extents.
  30.  
  31.  
  32. -- Kathy Jou
  33. -- Oracle Corporation
  34. -- Disclaimer:  I speak from my own experience and not for Oracle.
  35.  
  36.