On Wed, 2 Apr 2003, Steve Atkins wrote:
> On Wed, Apr 02, 2003 at 07:33:46PM -0500, John Wells wrote:
> > I have a M$ Sql Server db that I'm porting to postgresql. Approx. 24
> > tables from this old db can be combined in the new database into one
> > table, and it would be a bit more elegant to do this.
> >
> > However, the combined table would be around 95000 rows in size.
Almost laughably small :)
> >
> > Having never really used Postgresql in the past, and unable to find a
> > datapoint on the web, I would really like to get input from current users.
> > Is this an unreasonable table size to expect good performance when the
> > PHP app driving it gets a reasonable amount of traffic? I know
> > performance is also heavily dependent on indexes and query structure, but
> > disregarding either of those for the sake of argument, would I be better
> > off keeping the tables separate, or is 95000 not something to worry about?
> > btw, most tables in this database are quite small (<2000). My redesign
> > would create two tables in the +90000 range, but less than 100000.
> >
> > Thanks very much for your input.
>
> I have a number of 1,000,000-plus row tables (very plus in some cases)
> running on some nasty low-end (Celerons with 5400rpm IDE drives, Netras)
> and performance is quite adequate for typical use.
>
Yeah, it's those sequential and tsearch index scans that kill it but selective
queries fly.
--
Nigel J. Andrews
