From: | Łukasz Walkowski <lukasz(dot)walkowski(at)homplex(dot)pl> |
---|---|
To: | Craig James <cjames(at)emolecules(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Varchar vs foreign key vs enumerator - table and index size |
Date: | 2013-09-02 09:47:37 |
Message-ID: | 181A36F9-F0C5-457F-9C9C-502959359DD8@homplex.pl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 1 wrz 2013, at 03:31, Craig James <cjames(at)emolecules(dot)com> wrote:
> If your applications are read-heavy and only have a small-ish amount of code that inserts/updates the table, it may not be that much of a rewrite. You can create a integer/varchar table of key/values, use its key to replace the current varchar column, rename the original table, and create a view with the original table's name. Code that only reads the data won't know the difference. And it's a portable solution.
>
> I did this and it worked out well. If the key/value pairs table is relatively small, the planner does an excellent job of generating efficient queries against the big table.
>
> Craig
Actually this (event) table is write heavy. But the concept is really cool and worth trying. Thanks.
Lukasz
From | Date | Subject | |
---|---|---|---|
Next Message | Łukasz Walkowski | 2013-09-02 09:53:26 | Re: Varchar vs foreign key vs enumerator - table and index size |
Previous Message | Craig Ringer | 2013-09-02 07:46:06 | Re: How clustering for scale out works in PostgreSQL |