On Fri, Dec 14, 2012 at 3:34 PM, Kevin Grittner <kgri...@mail.com> 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?

Reply via email to