Re: Table partitioning problem

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

 



Alright thanks all of you for your answers, but i've got 3 more questions :
  1. Why "... partitionning is not a good idea ..." like you said Robert and Conor "... I grant that it would be better to never need to do that" ?
  2. Is there another way or strategy to deal with very large tables (over 100 000 000 rows per year in one table)  beyond indexing and partitionning?
  3. If you had to quantify a limit of numbers of rows per table in a single postgresql database server what would you say?
PS: i'm using postgresql since less than 2 month because i thought that partitioning was a possible solution  that doesn't offer me Apache Derby for my large table problem so if these questions sounds "dummy" for you this is a postgresql novice talking to you.

Regards

Le 14/03/2011 20:40, Robert Haas a écrit :
On Mon, Mar 14, 2011 at 12:42 PM, Samba GUEYE <samba.gueye@xxxxxxxxxxxx> wrote:
Yeah but is there a workaround to force the root table to propagate the
foreign key to the partitionned table
because right now all foreign keys to partitionned table throws constraints
violation and it's a big problem for me
No.  Generally, table partitioning is not a good idea unless you are
dealing with really large tables, and nearly all of your queries apply
only to a single partition.  Most likely you are better off not using
table inheritance in the first place if you need this feature.

It would be nice if we had a way to do this for the rare cases where
it would be useful, but we don't.



[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux