Обсуждение: capacity of tables

Поиск
Список
Период
Сортировка

capacity of tables

От
"guillermo arias"
Дата:
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 

Re: capacity of tables

От
"Harald Armin Massa"
Дата:
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: capacity of tables

От
Ron Johnson
Дата:
-----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-----

Re: capacity of tables

От
marcelo Cortez
Дата:
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