AI Rumman wrote: > The ENTITY table has 2164493 rows with data as follows: > > type | count > -----------------------+-------- > Contacts | 327352 > Candidate | 34668 > Emailst | 33604 > Calendar | 493956 > Contacts Image | 7 > PriceBooks | 2 > Notes Attachment | 17 > SalesOrder | 6 > Acc | 306832 > ... > .. > (29 rows) > > Do you think partitioning will improve the overall performance of > the application where all the queries have join with this table? I would not consider putting contacts, calendars, and sales orders in separate tables as "partitioning". It is normalizing. That will be useful if you happen to discover, for instance, that the data elements needed or relationships to other types of data for a calendar don't exactly match those for a contact image or a sales order. And yes, I would expect that using separate tables for fundamentally different types of data would improve performance. If some of these objects (like contacts and candidates) have common elements, you might want to either have both inherit from a common Person table, or (usually better, IMO) have both reference rows in a Person table. The latter is especially important if a contact can be a candidate and you want to be able to associate them. -Kevin -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
