On Tue, Mar 11, 2014 at 3:58 PM, Tomas Vondra <tv@fuzzy.cz> wrote:
> ERROR: index row size 1416 exceeds maximum 1352 for index "gin_idx"
All index AMs have similar restrictions.
> A good example of such header is "dkim-signature" which basically
> contains the whole message digitally signed with DKIM. The signature
> tends to be long and non-compressible, thanks to the signature.
>
> I'm wondering what's the best way around this, because I suspect many
> new users (especially those attracted by jsonb and GIN improvements)
> will run into this. Maybe not immediately, but eventully they'll try to
> insert a jsonb with long value, and it will fail ...
The jsonb_hash_ops operator class just stores a 32-bit integer hash
value (it always sets the recheck flag, which only some of the other
default GIN opclass' strategies do). It only supports containment, and
not the full variety of operators that the default opclass supports,
which is why it isn't the default. I think that in practice the
general recommendation will be that when indexing at the "top level",
use jsonb_hash_ops. When indexing nested items, use the more flexible
default GIN opclass. That seems like a pretty smart trade-off to me.
The more I think about it, the more inclined I am to lose GiST support
entirely for the time being. It lets us throw out about 700 lines of C
code, which is a very significant fraction of the total, removes the
one open bug, and removes the least understood part of the code. The
GiST opclass is not particularly compelling for this.
--
Peter Geoghegan