Re: Postgresql capabilities question
От | Nigel J. Andrews |
---|---|
Тема | Re: Postgresql capabilities question |
Дата | |
Msg-id | Pine.LNX.4.21.0304030756070.2573-100000@ponder.fairway2k.co.uk обсуждение исходный текст |
Ответ на | Re: Postgresql capabilities question (Steve Atkins <steve@blighty.com>) |
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: