Thread: capacity of tables
Hello, i am Guillermo Arias, from Peru. I have a doubt about capacity of tables.I am developing a software for accountants,and my principal problem is about the table for the vouchers. I have to decide to make a table for each yearor only one table for all the years. This table has 11 fields: varchar(10) and 2 fields: numeric (12,2) and is intendedto have 900,000 records per year x 13 years = 11'700,000 recordsWhat can you suggest me? i do not want the systemto be slow using this table.thanksguillermoariast@hotmail.com Get your FREE, LinuxWaves.com Email Now! -->http://www.LinuxWaves.comJoin Linux Discussions! --> http://Community.LinuxWaves.com
One table. If you need to split, you can allways do that via inheritance & constraint exclusion, thereby creating table partitioning.
Best wishes,
Harald
--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Reinsburgstraße 202b
70197 Stuttgart
0173/9409607
fx 01212-5-13695179
-
Python: the only language with more web frameworks than keywords.
Best wishes,
Harald
--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Reinsburgstraße 202b
70197 Stuttgart
0173/9409607
fx 01212-5-13695179
-
Python: the only language with more web frameworks than keywords.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/24/07 13:06, guillermo arias wrote: > Hello, i am Guillermo Arias, from Peru. I have a doubt about > capacity of tables. I am developing a software for accountants, > and my principal problem is about the table for the vouchers. I > have to decide to make a table for each year or only one table > for all the years. > > This table has 11 fields: varchar(10) and 2 fields: numeric > (12,2) and is intended to have 900,000 records per year x 13 > years = 11'700,000 records PostgreSQL will easily handle 12 million rows. > What can you suggest me? i do not want the system to be slow > using this table. Performance (*not* including hardware) is based on: 1. Well-written queries. 2. How the indexes match the queries. EXPLAIN ANALYZE is your friend!! 3. The knowledge that it is expensive to insert into/update/delete from an index, so create the indexes you need, but don't go crazy. 4. Continual monitoring: production usage patterns will probably be different from what you expected. Do not be surprised if you have to add or modify indexes "later on". 5. Using an up-to-date version of PostgreSQL. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFt7LsS9HxQb37XmcRAo8QAJwLjj26KiJl7gNvt6joKTuo6oGrIwCfWHcz y9EqHqWygdYKPss3J47TgUc= =jaMf -----END PGP SIGNATURE-----
People In my experience work very well con tables with 172.000.000 of records ( 172 millions). In fact is not too large number of records for postgresql. important aspect of this installation is your .conf file, take care of this, check old email with config subject. Best regards mdc --- Ron Johnson <ron.l.johnson@cox.net> escribió: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/24/07 13:06, guillermo arias wrote: > > Hello, i am Guillermo Arias, from Peru. I have a > doubt about > > capacity of tables. I am developing a software for > accountants, > > and my principal problem is about the table for > the vouchers. I > > have to decide to make a table for each year or > only one table > > for all the years. > > > > This table has 11 fields: varchar(10) and 2 > fields: numeric > > (12,2) and is intended to have 900,000 records per > year x 13 > > years = 11'700,000 records > > PostgreSQL will easily handle 12 million rows. > > > What can you suggest me? i do not want the system > to be slow > > using this table. > > Performance (*not* including hardware) is based on: > 1. Well-written queries. > 2. How the indexes match the queries. EXPLAIN > ANALYZE is your > friend!! > 3. The knowledge that it is expensive to insert > into/update/delete > from an index, so create the indexes you need, > but don't go > crazy. > 4. Continual monitoring: production usage patterns > will probably > be different from what you expected. Do not be > surprised if you > have to add or modify indexes "later on". > 5. Using an up-to-date version of PostgreSQL. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFFt7LsS9HxQb37XmcRAo8QAJwLjj26KiJl7gNvt6joKTuo6oGrIwCfWHcz > y9EqHqWygdYKPss3J47TgUc= > =jaMf > -----END PGP SIGNATURE----- > > ---------------------------(end of > broadcast)--------------------------- > TIP 6: explain analyze is your friend > __________________________________________________ Preguntá. Respondé. Descubrí. Todo lo que querías saber, y lo que ni imaginabas, está en Yahoo! Respuestas (Beta). ¡Probalo ya! http://www.yahoo.com.ar/respuestas