Search Postgresql Archives

Is It Good Practice That I use TableName-Month-Year Convention

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I realize the READ performance goes down dramatically when my table goes large. Every new day goes on, my table can increase x millions of new rows.

I was wondering whether this is good practice I can design my database in this way?

Instead of having

lot <-> unit <-> measurement

Can I have

lot-March-2010 <-> unit-March-2010 <-> measurement-March-2010
lot-April-2010 <-> unit-April-2010 <-> measurement-April-2010

(1) That's mean in my stored procedure, I need to dynamically generate the table name. Is this the "dynamic SQL" to correct way, to dynamically generate table name : http://www.postgresql.org/docs/8.1/interactive/ecpg-dynamic.html

(2) Is this consider a good approach, to overcome speed problem (especially read speed). Any potential problem I should put an eye on, before I implement this strategy?

Thanks and Regards
Yan Cheng CHEOK


      


-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux