From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | Arthur Silva <arthurprs(at)gmail(dot)com>, Larry White <ljw1001(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Peter Geoghegan <pg(at)heroku(dot)com>, Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz> |
Subject: | Re: jsonb format is pessimal for toast compression |
Date: | 2014-08-26 18:34:09 |
Message-ID: | 53FCD321.1050300@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 08/26/2014 07:51 AM, Tom Lane wrote:
> My feeling about it at this point is that the apparent speed gain from
> using offsets is illusory: in practically all real-world cases where there
> are enough keys or array elements for it to matter, costs associated with
> compression (or rather failure to compress) will dominate any savings we
> get from offset-assisted lookups. I agree that the evidence for this
> opinion is pretty thin ... but the evidence against it is nonexistent.
Well, I have shown one test case which shows where lengths is a net
penalty. However, for that to be the case, you have to have the
following conditions *all* be true:
* lots of top-level keys
* short values
* rows which are on the borderline for TOAST
* table which fits in RAM
... so that's a "special case" and if it's sub-optimal, no bigee. Also,
it's not like it's an order-of-magnitude slower.
Anyway, I called for feedback on by blog, and have gotten some:
http://www.databasesoup.com/2014/08/the-great-jsonb-tradeoff.html
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-08-26 18:40:04 | Re: jsonb format is pessimal for toast compression |
Previous Message | Tom Lane | 2014-08-26 18:27:45 | Re: Compute attr_needed for child relations (was Re: inherit support for foreign tables) |