On Tue, May 15, 2007 at 07:51:44AM +0200, Dawid Kuroczko wrote: > On 5/15/07, Bill Moseley <[EMAIL PROTECTED]> wrote: > >On Tue, May 15, 2007 at 06:33:26AM +0200, Dawid Kuroczko wrote: > >> Well, views are not going to help with memory consumption here. > >> It is the table contents that gets cached in buffer cache, not the > >> views contents. So if you have a view which returns only one > >> column from 15-column table, you will be caching that 15-column > >> data nonetheless. View, as the name states, is converted into > >> a select on a real table. > > > >Are you saying that in Postgresql: > > > > select first_name, last_name from user_table; > > > >uses the same memory as this? > > > > select first_name, last_name, > > passowrd, email, > > [10 other columns] > > from user_table; > > Yes. You read whole page (8KB) into buffer_cache, > then extract these columns from these buffer. From the > buffer cache point of view, whole tuple is contained in the > cache.
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 [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org/