Tom Lane wrote:
I wrote:
If we wanted to keep the lengths in the same 32 bits they presumably
occupy now, what about splitting 8/24 (=> 255 bytes for key, 24MB for
value)?
Sigh, fingers faster than brain today. A 24-bit length field could
represent lengths up to 16MB, not 24MB. Still, it seems like a
reasonable maximum.
Or we could increase the size of hstore values so as to provide more
than 32 bits total for this, but that would presumably be pessimal for
all existing applications; there is evidently no one using more than
64K, or we'd have heard complaints before.
Yeah, I have to say that it would never have occurred to me to use
hstore for large values like that; 64K is pretty much a whole page of
text. If you need to store that much data, use a real table. Or maybe
CouchDB.
As an hstore user, I'd be fine with simply limiting it to 64K (or, heck,
8K) and throwing an error. I'd also be fine with limiting keys to 255
bytes, although we'd have to warn people.
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
