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?