capacity of tables

Started by guillermo ariasabout 19 years ago4 messagesgeneral
Jump to latest
#1guillermo arias
guillermoariast@linuxwaves.com

<DIV style="font-family:Arial, sans-serif; font-size:10pt;"><FONT size="2"><SPAN style="font-family: Arial,sans-serif;">Hello, i am Guillermo Arias, from Peru. I have a doubt about capacity of tables.<BR>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. <BR><BR>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<BR><BR></SPAN></FONT><FONT size="2"><SPAN style="font-family: Arial,sans-serif;">What can you suggest me? i do not want the system to be slow using this table.<BR><BR>thanks<BR>guillermoariast@hotmail.com<BR><BR></SPAN></FONT><BR>&nbsp;<BR><HR>Get your FREE, LinuxWaves.com Email Now! --&gt; http://www.LinuxWaves.com&lt;BR&gt;Join Linux Discussions! --&gt; http://Community.LinuxWaves.com&lt;/DIV&gt;

#2Harald Armin Massa
haraldarminmassa@gmail.com
In reply to: guillermo arias (#1)
Re: 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.

#3Ron Johnson
ron.l.johnson@cox.net
In reply to: guillermo arias (#1)
Re: 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-----

#4marcelo Cortez
jmdc_marcelo@yahoo.com.ar
In reply to: Ron Johnson (#3)
Re: 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 <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