| From: | Jim Nasby <jim(at)nasby(dot)net> |
|---|---|
| To: | Łukasz Walkowski <lukasz(dot)walkowski(at)homplex(dot)pl> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Varchar vs foreign key vs enumerator - table and index size |
| Date: | 2013-09-12 15:07:55 |
| Message-ID: | 5231D8CB.4030907@nasby.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 8/31/13 8:35 AM, Łukasz Walkowski wrote:
> 3. And this part is most interesting for me. Columns browser, eventsource, eventtype, devicetype, operatingsystem contain a small pool of strings - for example for devicetype this is set to Computer, Mobile, Tablet or Unknown. Browser is set to normalized browser name. In every case I can store those data using one of 3 different methods:
Sorry for the late reply... the Enova Tools project in pgFoundry has code that lets you create a "dynamic lookup table" that allows for easily normalizing slow-changing data. You could then put a writable view on top of that so that the app wouldn't know the difference. It also has a backfill framework that would help you move data from the old table to the new table.
--
Jim C. Nasby, Data Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Nasby | 2013-09-12 15:10:08 | Re: Optimising views |
| Previous Message | Mikkel Lauritsen | 2013-09-12 13:29:28 | Re: Reasons for choosing one execution plan over another? |