[GENERAL] 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 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 recordsWhat can you suggest me? i do not want the system to be slow using this table.thanks[EMAIL PROTECTED] Get your FREE, LinuxWaves.com Email Now! --> http://www.LinuxWaves.comJoin Linux Discussions! --> http://Community.LinuxWaves.com
Re: [GENERAL] capacity of tables
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.
Re: [GENERAL] capacity of tables
-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
Re: [GENERAL] capacity of tables
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 <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
