Performance issues of one vs. two split tables.

Поиск
Список
Период
Сортировка
От Dawid Kuroczko
Тема Performance issues of one vs. two split tables.
Дата
Msg-id 758d5e7f0705142133s15a28ac9y68739b9c15cbd60d@mail.gmail.com
обсуждение исходный текст
Ответ на Performance issues of one vs. two split tables.  (Bill Moseley <moseley@hank.org>)
Ответы Re: Performance issues of one vs. two split tables.  (Bill Moseley <moseley@hank.org>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Recovering a messed-up database
Следующее
От: Bill Moseley
Дата:
Сообщение: Re: Performance issues of one vs. two split tables.