From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | Oleg Bartunov <obartunov(at)gmail(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Geoghegan <pg(at)heroku(dot)com>, Tomas Vondra <tv(at)fuzzy(dot)cz>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: jsonb and nested hstore |
Date: | 2014-03-13 13:21:01 |
Message-ID: | 5321B0BD.2090207@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 03/13/2014 08:42 AM, Greg Stark wrote:
> Fwiw the jsonb data doesn't actually seem to be any smaller than text
> json on this data set (this is avg(pg_column_size(col)) and I checked,
> they're both using the same amount of toast space)
>
> jsonb | json
> -------+-------
> 813.5 | 716.3
> (1 row)
That's expected, you save on whitespace, quotes and punctuation and
spend on structural overhead (e.g. string lengths). The actual strings
stored are the virtally the same. Numbers are stored as numerics, which
might or might not be longer. Nulls and booleans are about a wash.
>
> It's still more than 7x faster in cpu costs though:
>
> stark=# select count(attrs->'properties'->>'STREET') from citylots;
> count
> --------
> 196507
> (1 row)
>
> Time: 1026.678 ms
>
> stark=# select count(attrs->'properties'->>'STREET') from citylots_json;
> count
> --------
> 196507
> (1 row)
>
> Time: 7418.010 ms
>
That's also expected, it's one of the major benefits. With jsonb you're
avoiding reparsing the json.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-03-13 13:22:41 | Re: Is this a bug? |
Previous Message | Stephen Frost | 2014-03-13 13:17:53 | Re: [PATCH] Store Extension Options |