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
