Path: newssvr20.news.prodigy.com!newsmst01.news.prodigy.com!prodigy.com!prodigy.com!pd7cy2so!pd7cy1no!shaw.ca!news3.optonline.net!feed1.newsreader.com!newsreader.com!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sn-xit-03!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: Daniel Morgan Newsgroups: comp.databases.oracle.server Subject: Re: modifying and adding columns to a big table Date: Tue, 11 Nov 2003 12:44:42 -0800 Organization: ATS Message-ID: <1068583503.225763@yasure> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <1068484352.253581@yasure> <3FB0AF1C.30D7FE72@hotmail.com> In-Reply-To: <3FB0AF1C.30D7FE72@hotmail.com> Content-Type: multipart/alternative; boundary="------------060105020701060805040400" Cache-Post-Path: yasure!unknown@pond178.drizzle.com X-Cache: nntpcache 2.4.0b5 (see http://www.nntpcache.org/) X-Complaints-To: abuse@supernews.com Lines: 93 Xref: newssvr20.news.prodigy.com comp.databases.oracle.server:247466 --------------060105020701060805040400 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Rob Cowell wrote: >Daniel Morgan wrote: > > >>2. 1.3M rows is so small it is hardly worth partitioning. This is a very >>small table. I hope >>you didn't expend the money for EE just for this. >> >> > >That's a bit of a generalistaion. Partitioning can be for performance, >not just administration. > >I work with some similar sized (assuming his rows aren't 4Mb each, why >do people quote table sizes in numbers of rows?) tables that are hit >hundreds of times a day to read about a 10th of all the rows for report >generation, depending on the value of a certain key. Partitioning on >that key drastically reduces scan times, because we don't need to scan >the whole table, but an index wouldn't be selective enough to be worth >using. > > Tables that are ht hundreds of times per day to read about a 10th of the rows probably have all of the information cached in memory unless they are very large tables which is why my comment. -- Daniel Morgan http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp damorgan@x.washington.edu (replace 'x' with a 'u' to reply) --------------060105020701060805040400 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Rob Cowell wrote:
Daniel Morgan wrote:
  
2. 1.3M rows is so small it is hardly worth partitioning. This is a very
small table. I hope
you didn't expend the money for EE just for this.
    

That's a bit of a generalistaion. Partitioning can be for performance,
not just administration. 

I work with some similar sized (assuming his rows aren't 4Mb each, why
do people quote table sizes in numbers of rows?) tables that are hit
hundreds of times a day to read about a 10th of all the rows for report
generation, depending on the value of a certain key. Partitioning on
that key drastically reduces scan times, because we don't need to scan
the whole table, but an index wouldn't be selective enough to be worth
using.
Tables that are ht hundreds of times per day to read about a 10th of the rows probably
have all of the information cached in memory unless they are very large tables which is why
my comment.
-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)
--------------060105020701060805040400--