On 12/20/2010 05:22 PM, Ricardo Aráoz wrote: > 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. I explained before the project nature, and yes: these vectors are the bread and butter. Moreover, this would be a partial reengineering of a system with a 20 year successful history. Some years ago, we tried the join model, and it's painfully slow. > r > > _______________________________________________ > 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] >
_______________________________________________ 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]
