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
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
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
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
. 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
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
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