Path: newssvr20.news.prodigy.com!newsmst01.news.prodigy.com!prodigy.com!prodigy.com!newsfeed.cwix.com!newsfeed.stueberl.de!newsr1.ipcore.viaginterkom.de!btnet-peer1!btnet-feed5!btnet!news.intra.bt.com!not-for-mail From: Rob Cowell Newsgroups: comp.databases.oracle.server Subject: Re: modifying and adding columns to a big table Date: Tue, 11 Nov 2003 09:42:52 +0000 (UTC) Organization: not organized Lines: 18 Message-ID: <3FB0AF1C.30D7FE72@hotmail.com> References: <1068484352.253581@yasure> NNTP-Posting-Host: 10.224.110.46 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: visp.bt.co.uk 1068543772 23631 10.224.110.46 (11 Nov 2003 09:42:52 GMT) X-Complaints-To: newsmaster@news.intra.bt.com NNTP-Posting-Date: Tue, 11 Nov 2003 09:42:52 +0000 (UTC) X-Accept-Language: en X-Mailer: Mozilla 4.7 [en-gb]C-CCK-MCD (WinNT; U) Xref: newssvr20.news.prodigy.com comp.databases.oracle.server:247433 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.