Message-ID: <54989022.9010305@dunslane.net>
Date: Mon, 22 Dec 2014 16:41:54 -0500
From: Andrew Dunstan <andrew@dunslane.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Robert DiFalco <robert.difalco@gmail.com>,
 "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: Number of Columns and Update
References: 
 <CAAXGW-xXFDWHEBJExt40bWD1+vOo6_UbytCUjEe625GqBXmxUA@mail.gmail.com>
In-Reply-To: 
 <CAAXGW-xXFDWHEBJExt40bWD1+vOo6_UbytCUjEe625GqBXmxUA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org


On 12/22/2014 03:53 PM, Robert DiFalco wrote:
> This may fall into the category of over-optimization but I've become 
> curious.
>
> I have a user table with about 14 columns that are all 1:1 data - so 
> they can't be normalized.
>
> When I insert a row all columns need to be set. But when I update, I 
> sometimes only update 1-2 columns at a time. Does the number of 
> columns impact update speed?
>
> For example:
>      UPDATE users SET email = ? WHERE id = ?;
>
> I can easily break this up into logical tables like user_profile, 
> user_credential, user_contact_info, user_summary, etc with each table 
> only having 1-4 columns. But with the multiple tables I would often be 
> joining them to bring back a collection of columns.
>
> I know I'm over thinking this but I'm curious of what the performance 
> trade offs are for breaking up a table into smaller logically grouped 
> tables.
>
>

An update rewrites the whole row, not just the updated columns.

I think you are overthinking it.

cheers

andrew


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance