On 20/12/2010 05:02 p.m., Ed Leafe wrote: > On Dec 20, 2010, at 2:44 PM, Ricardo Aráoz wrote: > >>>> No, of course not. But why would I not want to do a join? >>> Joins are slow. >> As compared to what? How does Postgres keep the info behind the scenes? >> And if it does not use Joins then it must use some other method that >> will slow you down on input or update or delete or join. After all, >> there are no free rides, otherwise everybody would be getting one. > This is Database Design 101. > > Single-table reads are the fastest. Fully-indexed joins are slower, > followed by paritally-indexed joins, followed by unindexed joins. > > Full normalization maximizes the number of joins required to retrieve > the data, and is generally avoided for more reasonable levels of > normalization. If you have a table with info on people, do you create > separate FirstName, MiddleName and LastName tables, and then only store the > index to each part of someone's name in the Person table? Or do you make a > FirstName, etc., column, and accept the fact that there will be multiple > entries for some names (which is a no-no for normalization)? > > I don't know PostgreSQL's internals, but I've never come across a > database system in which a single-table read was not significantly faster > than a join.
Not to optimize ahead of time is programming 101. Will the table will be accessed mostly to use the vectors? Or maybe the most common use is not to access them (in which case you are spending resources in reading worthless data)? What will the size of these vectors be? Is the optimization meaningful and worth the denormalization? Is there a *real* performance issue requiring this? BTW, using vectors in a table does not strike me as easy as using FirstName in the same table. Unless I want to make a silly point. _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/[email protected]
