Re: [PERFORM] Database design - best practice

2012-11-28 Thread Jeff Janes
On Wed, Nov 28, 2012 at 4:41 AM, Niels Kristian Schjødt wrote: > > So my main concern is actually about the cars table, since this one currently > has a lot of columns (151 - I expect thats quite a lot?), and a lot of data > (4 mil. rows, and growing). Now you might start by thinking, this could

Re: [PERFORM] Database design - best practice

2012-11-28 Thread Vitalii Tymchyshyn
Let me be devil advocate here :) First of all, even if you read any basics about normalization, don't take it to your heart :) Think. Know that each normalization/denormalization step has it's cons and pros. E.g. in NoSQL world they often don't normalize much. What's interesting with PosgreSQL is t

Re: [PERFORM] Database design - best practice

2012-11-28 Thread Kevin Grittner
Niels Kristian Schjødt wrote: > So my main concern is actually about the cars table, since this > one currently has a lot of columns (151 - I expect thats quite a > lot?), That's pretty wide, but not outrageous. > and a lot of data (4 mil. rows, and growing). That's not a big deal. It's not unu

Re: [PERFORM] Database design - best practice

2012-11-28 Thread Bèrto ëd Sèra
Hi Kristian, > " I can't see why it would make sense to put that into a separate table and > join in the values " > You don't normalize for performance. People DEnormalize for performance. Yes. In short, you seem more of a developer than a RDBMS guy. This is not a personal fault, but it's a *very

Re: [PERFORM] Database design - best practice

2012-11-28 Thread Willem Leenen
. I don't count the number of rows, but number of blocks (pages) that are modified, which are 8K each. My advice would be to first establish a solutiondirection via diagnosing the problem. My experience is that most solutions are not obscure at all. Subject: Re: [PERFORM] Database d

Re: [PERFORM] Database design - best practice

2012-11-28 Thread Niels Kristian Schjødt
Thanks for the advice. Currently I see a lot of I/O related to update/inserts, so I'm trying to track down these guys at first. In relation to question 2, I read somewhere in the documentation that because of MVCC, the whole row has to be rewritten even though I just update one single column in

Re: [PERFORM] Database design - best practice

2012-11-28 Thread Willem Leenen
Niels, " I can't see why it would make sense to put that into a separate table and join in the values " You don't normalize for performance. People DEnormalize for performance. Questions: (AFAIK) 1) This is a way to disaster. Get yourself a book on RDBMS from for example Celko. Do