Re: modifying and adding columns to a big table

> Daniel Morgan wrote:
>
> 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_at_x.washington.edu
> (replace 'x' with a 'u' to reply)

Except that buffer reads are reduced by 90% for every query execution. Whether that's much of an issue would depend on the precise nature of the application and hardware, which I confess I'm not familiar with on Cris's system. Received on Wed Nov 12 2003 - 03:49:41 CST