On Fri, Dec 14, 2012 at 3:34 PM, Kevin Grittner <[email protected]> wrote:
> Claudio Freire wrote:
>
> > Selectivity is decided based on the number of distinct values on
> > both sides, and the table's name "entity" makes me think it's a
> > table that is reused for several things. That could be a problem,
> > since that inflates distinct values, feeding misinformation to
> > the planner.
> >
> > Rather than a generic "entity" table, perhaps it would be best to
> > separate them different entities into different tables.
>
> I missed that; good catch. Good advice.
>
> Don't try to build a "database within a database" by having one
> table for different types of data, with a code to sort them out.
> EAV is a seriously bad approach for every situation where I've seen
> someone try to use it. I was about to say it's like trying to drive
> a nail with a pipe wrench, then realized it's more like putting a
> bunch of hammers in a bag and swinging the bag at the nail.
>
> -Kevin
>
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?
