Re: Performance issues of one vs. two split tables.
| От | SCassidy@overlandstorage.com |
|---|---|
| Тема | Re: Performance issues of one vs. two split tables. |
| Дата | |
| Msg-id | OF0ECC0667.7FBB69AE-ON882572DC.00642CDD-882572DC.006448F9@overlandstorage.com обсуждение исходный текст |
| Ответ на | Re: Performance issues of one vs. two split tables. (Bill Moseley <moseley@hank.org>) |
| Список | pgsql-general |
One other possible reason for splitting the table up in two chunks is to grant different rights on the 2 sets of columns.
Susan Cassidy
| Bill Moseley <moseley@hank.org> Sent by: pgsql-general-owner@postgresql.org 05/15/2007 09:44 AM |
|
Sorry, I don't mean to drag this thread out much longer. But, I have
one more question regarding joins.
Say I have a customer table and an order table. I want a list of all
order id's for a given customer.
SELECT o.id
FROM order o
JOIN customer c on o.customer = c.id
Does that bring into memory all columns from both order and customer?
Maybe that's not a good example due to indexes.
See, I've seen this splitting of one-to-one tables a number of time
(such as the user and user_preferences example) and I'm not sure if
that's just poor schema design, premature optimization, or someone
making smart use of their knowledge of the internal workings of
Postgresql....
--
Bill Moseley
moseley@hank.org
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org/
----------------------------------------------------------------------------------------------
Simply protected storage solutions ensure that your information is
automatically safe, readily available and always there, visit us at http://www.overlandstorage.com
----------------------------------------------------------------------------------------------
В списке pgsql-general по дате отправления: