Performance issues of one vs. two split tables. - Mailing list pgsql-general

From Dawid Kuroczko
Subject Performance issues of one vs. two split tables.
Date
Msg-id 758d5e7f0705142133s15a28ac9y68739b9c15cbd60d@mail.gmail.com
Whole thread Raw
In response to Performance issues of one vs. two split tables.  (Bill Moseley <moseley@hank.org>)
Responses Re: Performance issues of one vs. two split tables.
List pgsql-general
On 5/14/07, Rich Shepard <rshepard@appl-ecosys.com> wrote:
> On Mon, 14 May 2007, PFC wrote:
>
> >       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.
> >       So I split the table, and it was faster.
> >
> >       However, you can also buy more RAM...
>
>    Or, use Views without paying more.

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.

As for actual colors table -- you might consider keeping colors
as int[] (integer array) column, though I'll never admit I suggeted
you that. :D

   Regards,
        Dawid

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Recovering a messed-up database
Next
From: Bill Moseley
Date:
Subject: Re: Performance issues of one vs. two split tables.