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