From: | Dorian Hoxha <dorian(dot)hoxha(at)gmail(dot)com> |
---|---|
To: | Tim Kane <tim(dot)kane(at)gmail(dot)com> |
Cc: | pgsql-general General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: hstore binary representation of keys |
Date: | 2014-04-22 12:18:45 |
Message-ID: | CANsFX07i899x1JcUCsPjec8SC-S4Yi4uLrK3yevh9Ec2x1QqDA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Currently hstore is mongodb. It writes the keys everytime (and values as
strings!, its mostly for dynamic keys or very sparse keys in my opinion).
You can shorten keys,or put them in dedicated columns.
I haven't read that there is a plan to compress the strings.
On Tue, Apr 22, 2014 at 2:01 PM, Tim Kane <tim(dot)kane(at)gmail(dot)com> wrote:
> Hi all,
>
> I’ve been using hstore to record various key/val pairs, but I’ve noticed
> it consumes a lot more disk than I would have expected.
> I don’t have any hard figures to illustrate, but empirical testing has
> shown that if I record these pairs as traditional column based fields, I
> can save a significant amount of disk.
>
> What I think I’m seeing here, is that the hstore representation needs to
> store the entirety of the *key* alongside each *value*.
>
> Let’s say I have a table of 1000 records, and 900 of them have a key named
> ‘A_REALLY_REALLY_REALLY_LONG_KEY’, then this key will be written do disk
> 900 times, along with the appropriate values.
>
>
> I guess there are two options open to me here.
>
>
> 1. I could transpose these values into a dedicated field
> 2. I could use shorter key names
>
>
> Does hstore2 go any way to improving this situation? Some kind of
> enumerated key based system?
>
>
>
> Cheers,
>
> TIm
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Ian Barwick | 2014-04-22 12:21:38 | Re: Fwd: How to ignore blank lines with file_fdw |
Previous Message | Albe Laurenz | 2014-04-22 12:16:26 | Re: How to ignore blank lines with file_fdw |