> What's more, it looks like the jsonb data is pretty much never getting
> compressed --- the min is too high for that. So I'm guessing that this
> example is mostly about the first_success_by threshold preventing any
> compression from happening. Please, before looking at my other patch,
> try this: in src/backend/utils/adt/pg_lzcompress.c, change line 221
> thusly:
>
> - 1024, /* Give up if no
> compression in the first 1KB */
> + INT_MAX, /* Give up if no
> compression in the first 1KB */
>
> then reload the jsonb data and give us the same stats on that.
That helped things, but not as much as you'd think:
postgres=# select pg_size_pretty(pg_total_relation_size('jsonic'));
pg_size_pretty
----------------
394 MB
(1 row)
postgres=# select pg_size_pretty(pg_total_relation_size('jsonbish'));
pg_size_pretty
----------------
801 MB
(1 row)
What I find really strange is that the column size distribution is
exactly the same:
thetype | colsize_distribution
---------+----------------------------
json | {1777,1803,1890,1940,4424}
jsonb | {5902,5926,5978,6002,6208}
Shouldn't the lower end stuff be smaller?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
