Re: Performance issues of one vs. two split tables.

From: Bill Moseley <moseley(at)hank(dot)org>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Performance issues of one vs. two split tables.
Date: 2007-05-14 20:53:13
Message-ID: 20070514205313.GB14273@hank.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, May 14, 2007 at 10:52:13PM +0200, PFC wrote:
>
> >Say I have a "user" table that has first, last, email, password, and
> >last_accessed columns. This user table will be accessed often. (It's
> >not really "user", but that's not important in this discussion)
> >
> >Say that there's also about 10 columns of settings or preferences for
> >each user. Are there any cases or reasons to have a separate
> >"user_preferences" table vs. just placing all the columns together in
> >one table?
>
> I did something like that on MySQL some time ago.
> In the Users table there was stuff that other users need to see
> (like his login name, etc), and stuff that only this user needs to see
> (like his preferences).

> So, when displaying posts in the forum, for instance, only a small
> part of the fields in the Users table was needed, the rest was just dead
> weight, that made the table unable to fit in RAM.

Well, that's part of my question. If not selecting those columns in
the common selects how much "dead weight" is brought along due to the
extra columns defined in the table, if any?

--
Bill Moseley
moseley(at)hank(dot)org

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Rich Shepard 2007-05-14 20:58:41 Re: Performance issues of one vs. two split tables.
Previous Message PFC 2007-05-14 20:52:13 Re: Performance issues of one vs. two split tables.