Re: [GENERAL] jsonb

On 11/14/2017 2:30 PM, hmidi slim wrote: I'm trying to use the function to_jsonb and create the name: to_jsonb ('{"key1":" ' || 'text1' || '","key2":" ' || 'text2' || '"}'); But after that I used Objection.js ORM to get data using the query: Product.query().where('id',1).then(prod =>

Re: [GENERAL] jsonb

On 11/14/2017 11:30 PM, hmidi slim wrote: > I'm trying to use the function to_jsonb and create the name: > to_jsonb ('{"key1":" ' || 'text1' || '","key2":" ' || 'text2' || '"}'); This query converts a string into a JSON object that consist of that string. I guess what you intend to accomplish is

Re: [GENERAL] jsonb

On Tue, Nov 14, 2017 at 4:30 PM, hmidi slim wrote: > I'm trying to use the function to_jsonb and create the name: > to_jsonb ('{"key1":" ' || 'text1' || '","key2":" ' || 'text2' || '"}'); > But after that I used Objection.js ORM to get data using the query: >

Re: [GENERAL] jsonb

I'm trying to use the function to_jsonb and create the name: to_jsonb ('{"key1":" ' || 'text1' || '","key2":" ' || 'text2' || '"}'); But after that I used Objection.js ORM to get data using the query: Product.query().where('id',1).then(prod => {console.log(prod)}) I think that the problem maybe

Re: [GENERAL] jsonb

On Tue, Nov 14, 2017 at 3:32 PM, hmidi slim wrote: > I have a column name of type 'jsonb' on my table named product. The format > of the column: > name: {"key1": "text1", "key2": "text2"} > > When I make a query to fetch data from the table I got this format: > name:

[GENERAL] jsonb

I have a column name of type 'jsonb' on my table named product. The format of the column: name: {"key1": "text1", "key2": "text2"} When I make a query to fetch data from the table I got this format: name: '{"key1": "text1", "key2": "text2"}' Why does postgresql returns the name such as string

Re: [GENERAL] jsonb case insensitive search

On Jun 1, 2017, at 13:44 , Karl Czajkowski wrote: > If I remember correctly, isn't a compound index always just using > btree? In general, I have found better luck using several smaller > btree indices than one large compound one. Unless your entire query > can be answered from

Re: [GENERAL] jsonb case insensitive search

On Jun 01, armand pirvu modulated: > Overall could it be that the optimizer blatantly ignores a scan index which > is cheaper than a table scan, or jsonb implementation still has a long way to > come up or the way it is used in my case is not the one designed for ? > If I remember correctly,

Re: [GENERAL] jsonb case insensitive search

I apologize before hand replying again on my own reply . I know it is frowned upon . My inline comments. > On Jun 1, 2017, at 2:05 PM, armand pirvu wrote: > > Thank you Karl and David > > Ideally as far as I can tell the index would need to be show_id, file_id, >

Re: [GENERAL] jsonb case insensitive search

Thank you Karl and David Ideally as far as I can tell the index would need to be show_id, file_id, lower(…) The question is if this is possible ? Thanks Armand > On Jun 1, 2017, at 12:24 PM, Karl Czajkowski wrote: > > On May 31, armand pirvu modulated: > >> The idea is

Re: [GENERAL] jsonb case insensitive search

On May 31, armand pirvu modulated: > The idea is that I would like to avoid having an index for each key > possibly wanted to search, but rather say have the whole record then > search by the key and get the key value, thus having one index serving > multiple purposes so to speak > First,

Re: [GENERAL] jsonb case insensitive search

> On May 31, 2017, at 2:32 PM, David G. Johnston > wrote: > > On Wed, May 31, 2017 at 12:18 PM, armand pirvu > wrote: > > For the example mentioned > > SELECT * > FROM cfg_files_data > WHERE

Re: [GENERAL] jsonb case insensitive search

On Wed, May 31, 2017 at 12:18 PM, armand pirvu wrote: > > For the example mentioned > > SELECT * > FROM cfg_files_data > WHERE cfg_files_data.show_id = 32 > AND cfg_files_data.file_id = 123 > AND lower((file_data_record ->> 'Company')) = lower('CompuTestSystems'); > ; > >

[GENERAL] jsonb case insensitive search

Hi The goal would be to be able to search case insensitive by any key:value combined with some other columns like outlined below, but initially would be Company:CompuTestSystems A sample would be SELECT * FROM cfg_files_data WHERE cfg_files_data.show_id = 32 AND cfg_files_data.file_id =

Re: [GENERAL] JSONB Overlap Operator.

On Fri, Mar 17, 2017 at 9:43 AM, Eduardo Felipe wrote: > Hi there! > > In a project I was experimenting with replacing array columns with JSONB > columns, to allow a greater flexibility of types. > > One thing that I found missing is the "overlap" operator (&&). > > JSONB

[GENERAL] JSONB Overlap Operator.

Hi there! In a project I was experimenting with replacing array columns with JSONB columns, to allow a greater flexibility of types. One thing that I found missing is the "overlap" operator (&&) . JSONB includes all other

Re: [GENERAL] Jsonb extraction very slow

On 8/16/16 10:19 AM, Tom Lane wrote: [ thinks for a bit... ] In principle we could have the planner notice whether there are multiple references to the same Var of a varlena type, and then cue the executor to do a pre-emptive detoasting of that field of the input tuple slot. But it would be

Re: [GENERAL] Jsonb extraction very slow

Jim Nasby writes: > On 8/11/16 8:45 AM, Tom Lane wrote: >> What were you doing to "get ten keys out"? If those were ten separate >> JSON operators, they'd likely have done ten separate decompressions. >> You'd have saved something by having the TOAST data already

Re: [GENERAL] Jsonb extraction very slow

On 8/11/16 8:45 AM, Tom Lane wrote: Jim Nasby writes: I never dug into why. As Tom posited, decompression might explain the time to get a single key out. Getting 10 keys instead of just 1 wasn't 10x more expensive, but it was significantly more expensive than just

Re: [GENERAL] Jsonb extraction very slow

On Thu, Aug 11, 2016 at 8:45 AM, Tom Lane wrote: > Jim Nasby writes: >> I never dug into why. As Tom posited, decompression might explain the >> time to get a single key out. Getting 10 keys instead of just 1 wasn't >> 10x more expensive, but it was

Re: [GENERAL] Jsonb extraction very slow

What were you doing to "get ten keys out"? If those were ten separate JSON operators, they'd likely have done ten separate decompressions. You'd have saved something by having the TOAST data already fetched into shared buffers, but it'd still hardly be free. Now i got the point.

Re: [GENERAL] Jsonb extraction very slow

Jim Nasby writes: > I never dug into why. As Tom posited, decompression might explain the > time to get a single key out. Getting 10 keys instead of just 1 wasn't > 10x more expensive, but it was significantly more expensive than just > getting a single key. What

Re: [GENERAL] Jsonb extraction very slow

Please CC the list. On 8/11/16 2:19 AM, hari.prasath wrote: Actually I've done some testing with this and there is a *significant* overhead in getting multiple keys from a large document. There's a significant extra cost for the first key, but there's also a non-trivial cost for every key after

Re: [GENERAL] Jsonb extraction very slow

On 8/9/16 9:29 AM, Tom Lane wrote: "hari.prasath" writes: I am using jsonb for storing key-value pair information(500 keys) and it was a very big data set with some 10M rows. Whenever i try to extract some keys(let say some 10 keys and its values) its really

Re: [GENERAL] Jsonb extraction very slow

"hari.prasath" writes: > I am using jsonb for storing key-value pair information(500 keys) and it > was a very big data set with some 10M rows. Whenever i try to extract some > keys(let say some 10 keys and its values) its really very slow. > Is this due to jsonb

[GENERAL] Jsonb extraction very slow

Hi all I am using jsonb for storing key-value pair information(500 keys) and it was a very big data set with some 10M rows. Whenever i try to extract some keys(let say some 10 keys and its values) its really very slow. Is this due to jsonb parsing (or) each time json will be loaded from

Re: [GENERAL] jsonb search

On Tue, Jun 28, 2016 at 5:09 PM, Oleg Bartunov wrote: > On Tue, Jun 28, 2016 at 5:15 PM, Armand Pirvu (home) > wrote: > > Hi > > > > In my quest of JSONB querying and searching without having to actually > cast > > into a text, I found JSQuery > > >

Re: [GENERAL] jsonb search

On Tue, Jun 28, 2016 at 5:15 PM, Armand Pirvu (home) wrote: > Hi > > In my quest of JSONB querying and searching without having to actually cast > into a text, I found JSQuery > > I do admit my JSONB knowledge shortcoming and I am not a developer but a > DBA. As such some

[GENERAL] jsonb search

Hi In my quest of JSONB querying and searching without having to actually cast into a text, I found JSQuery I do admit my JSONB knowledge shortcoming and I am not a developer but a DBA. As such some examples would be greatly appreciated since I tend to understand better I compiled and

Re: [GENERAL] JSONB performance enhancement for 9.6

No, it is within the individual json object storage. In a way, it would be part of query plan, but strictly for the individual json object storage structure, it is not necessarily an "index" one possible(but primitive) implementation could be like having multiple "segments" in the storage, all

Re: [GENERAL] JSONB performance enhancement for 9.6

On Sun, May 1, 2016 at 6:46 AM, Tom Smith wrote: > Hello: > > I'd like to bring this JSONB performance issue again. > Below is a link of MySQL way of storing/retrieving Json key/value > > https://dev.mysql.com/doc/refman/5.7/en/json.html > > Instead of providing column

Re: [GENERAL] JSONB performance enhancement for 9.6

Hello: I'd like to bring this JSONB performance issue again. Below is a link of MySQL way of storing/retrieving Json key/value https://dev.mysql.com/doc/refman/5.7/en/json.html Instead of providing column indexing(like GIN for JSONB in Postgresql). it provides only internal data structure level

Re: [GENERAL] JSONB performance enhancement for 9.6

On 20/01/16 13:32, Bill Moran wrote: On Tue, 19 Jan 2016 23:53:19 -0300 Alvaro Herrera wrote: Bill Moran wrote: As far as a current solution: my solution would be to decompose the JSON into an optimized table. I.e.: CREATE TABLE store1 ( id SERIAL PRIMARY KEY,

Re: [GENERAL] JSONB performance enhancement for 9.6

Using JSON/JSONB type in postgresql is usually due to the use case that the keys (top level included) can not be predefined. this is the major difference between NoSQL/Document and RDBMS. Why would TOAST have to be used? Can some speciailly structured "raw" files be used outside current

Re: [GENERAL] JSONB performance enhancement for 9.6

On Wed, Jan 20, 2016 at 4:51 AM, Bruce Momjian wrote: > On Mon, Jan 11, 2016 at 09:01:03PM -0500, Tom Smith wrote: > > Hi, > > > > Congrats on the official release of 9.5 > > > > And I'd like bring up the issue again about if 9.6 would address the > jsonb > > performance issue

Re: [GENERAL] JSONB performance enhancement for 9.6

Is there any database that actually supports what the original poster wanted ? The only thing that I know that's similar is bigtable/hbase/hypertable wide column store. The way it works is: break the lexicographically sorted rows into blocks of compressed XXKB, and then keeps an index on the

Re: [GENERAL] JSONB performance enhancement for 9.6

On Tue, 19 Jan 2016 23:53:19 -0300 Alvaro Herrera wrote: > Bill Moran wrote: > > > As far as a current solution: my solution would be to decompose the > > JSON into an optimized table. I.e.: > > > > CREATE TABLE store1 ( > > id SERIAL PRIMARY KEY, > > data JSONB > >

Re: [GENERAL] JSONB performance enhancement for 9.6

Bill Moran wrote: > As far as a current solution: my solution would be to decompose the > JSON into an optimized table. I.e.: > > CREATE TABLE store1 ( > id SERIAL PRIMARY KEY, > data JSONB > ); > > CREATE TABLE store2 ( > id INT NOT NULL REFERENCES store1(id), > top_level_key

Re: [GENERAL] JSONB performance enhancement for 9.6

On Mon, Jan 11, 2016 at 09:01:03PM -0500, Tom Smith wrote: > Hi, > > Congrats on the official release of 9.5 > > And I'd like bring up the issue again about if 9.6 would address the jsonb > performance issue > with large number of top level keys. > It is true that it does not have to use JSON

Re: [GENERAL] JSONB performance enhancement for 9.6

Hi, Congrats on the official release of 9.5 And I'd like bring up the issue again about if 9.6 would address the jsonb performance issue with large number of top level keys. It is true that it does not have to use JSON format. it is about serialization and fast retrieval of dynamic tree

Re: [GENERAL] JSONB performance enhancement for 9.6

On 11/29/15 9:30 AM, Arthur Silva wrote: Is this correct? I'm fairly sure jsonb supports lazily parsing objects and each object level is actually searched using binary search. The problem is there's no support for loading just part of a TOASTed field. Even if that existed, we'd still need a

Re: [GENERAL] JSONB performance enhancement for 9.6

Bill Moran writes: > Tom Smith wrote: >> Is there a plan for 9.6 to resolve the issue of very slow >> query/retrieval of jsonb fields when there are large number (maybe >> several thousands) of top level keys. Currently, if I save a large >>

Re: [GENERAL] JSONB performance enhancement for 9.6

Hi: The goal is fast retrieval of a a field value with a row when the row is already picked, one scenario is download a particular field value (if exists) of all rows in the table. It is actually a very common use case of exporting data of several user selected fields. The performance is

Re: [GENERAL] JSONB performance enhancement for 9.6

On Sun, 29 Nov 2015 08:24:12 -0500 Tom Smith wrote: > Hi, Thanks for everyone's response. > > The issue is not just compression, but lack of "indexing" or "segmentation" > when a > single doc has, say 2000 top level keys (with multiple levels of subkeys). > right now,

Re: [GENERAL] JSONB performance enhancement for 9.6

Hi, Thanks for everyone's response. The issue is not just compression, but lack of "indexing" or "segmentation" when a single doc has, say 2000 top level keys (with multiple levels of subkeys). right now, if I query for one key, the whole doc has to be first uncompressed and loaded and then

Re: [GENERAL] JSONB performance enhancement for 9.6

Unfortunately, the keys can not be predefined or fixed. it is a doc, the reason jsonb is used. It works well for small docs with small number of keys. but really slow with large number of keys. If this issue is resolved, I think Postgresql would be an absolutely superior choice over MongoDB.for

Re: [GENERAL] JSONB performance enhancement for 9.6

On Sat, 28 Nov 2015 21:27:51 -0500 Tom Smith wrote: > > Is there a plan for 9.6 to resolve the issue of very slow query/retrieval > of jsonb fields > when there are large number (maybe several thousands) of top level keys. > Currently, if I save a large json document

Re: [GENERAL] JSONB performance enhancement for 9.6

Hi: On Sun, Nov 29, 2015 at 1:09 PM, Bill Moran wrote: > On Sat, 28 Nov 2015 21:27:51 -0500 >> Currently, if I save a large json document with top level keys of thousands ** LARGE ** > The default storage for a JSONB field is EXTENDED. Switching it to > EXTERNAL will

Re: [GENERAL] JSONB performance enhancement for 9.6

Tom Smith schrieb am 29.11.2015 um 03:27: Hello: Is there a plan for 9.6 to resolve the issue of very slow query/retrieval of jsonb fields when there are large number (maybe several thousands) of top level keys. Currently, if I save a large json document with top level keys of thousands and

Re: [GENERAL] JSONB performance enhancement for 9.6

Is this correct? I'm fairly sure jsonb supports lazily parsing objects and each object level is actually searched using binary search. Em 29/11/2015 11:25 AM, "Tom Smith" escreveu: > Hi, Thanks for everyone's response. > > The issue is not just compression, but lack of

Re: [GENERAL] JSONB performance enhancement for 9.6

On 11/28/2015 6:27 PM, Tom Smith wrote: Is there a plan for 9.6 to resolve the issue of very slow query/retrieval of jsonb fields when there are large number (maybe several thousands) of top level keys. Currently, if I save a large json document with top level keys of thousands and

[GENERAL] JSONB performance enhancement for 9.6

Hello: Is there a plan for 9.6 to resolve the issue of very slow query/retrieval of jsonb fields when there are large number (maybe several thousands) of top level keys. Currently, if I save a large json document with top level keys of thousands and query/retrieve field values, the whole

Re: [GENERAL] jsonb value retrieval performance

does it read in the whole jsonb tree structure in memory and get to v1 or it has some optimization so only get v1 instead of reading in the whole structure. it reads, untoasts and uncompresses whole value and then executes search. An idea to fix that is a reading jsonb value by only needed

Re: [GENERAL] jsonb value retrieval performance

It can be any jsonb so I am asking a general question of the implementaion for each jsonb storage (not about GIN or table wide indexing, but only within a single jsonb item in a single row. A sample would be like (no quotes) { a1: {b1:v1, b2:v2, b100:v100} a3000: {c1:x1, c2: x2. c200: v200 }

Re: [GENERAL] jsonb value retrieval performance

and I am trying to get value via jsonb->parentKey->childKey it seems it is very slow. Would it be actually faster to use top level key only and parse it at client side? Suppose, most time is spent for decompressing huge value, not for actual search inside jsonb. If so, we need to implement

Re: [GENERAL] jsonb value retrieval performance

Suppose, most time is spent for decompressing huge value, not for actual search inside jsonb. If so, we need to implement some search method which decompress some chunks of jsonb. On artificial example: %SAMP IMAGE FUNCTION CALLERS 92.9 postgres pglz_decompress

[GENERAL] jsonb value retrieval performance

Hello: Does JSONB storage has some internal indexing(like hasmap) to fast look up a value given a key? I have a jsonb doc with two level keys (parentKey: {childKey:value}} there are maybe 2000 parent keys per doc and 100 child keys per parent key and I am trying to get value via

Re: [GENERAL] JSONB matching element count

On Sun, May 31, 2015 at 11:07 PM, Arup Rakshit arupraks...@rocketmail.com wrote: Hi, This says if matched found or not against the input array : '{a:1, b:2, c:3}'::jsonb ?| array['b', 'c'] But how would I determine how many matched ? Like for the above example, I see only 2 matched found.

[GENERAL] JSONB matching element count

Hi, This says if matched found or not against the input array : '{a:1, b:2, c:3}'::jsonb ?| array['b', 'c'] But how would I determine how many matched ? Like for the above example, I see only 2 matched found. -- Regards, Arup Rakshit Debugging is twice as

[GENERAL] JSONB spaces in text presentation

Hi. Is spaces is necessary in text presentation of JSONB? In my data resulting text contains ~12% of spaces. I'm developing web application, and want to get json-string from pg and send it to browser without repacking. -- С уважением, Ащепков Илья koc...@gmail.com

[GENERAL] JSONB spaces in text presentation

Hi. Is spaces is nessesary in text presentation of JSONB? In my data resulting text contains ~12% of spaces. I'm developing web application, and want to get json-string from pg and send it to browser without repacking. -- С уважением, Ащепков Илья koc...@gmail.com

Re: [GENERAL] JSONB spaces in text presentation

On 9/24/2014 12:23 AM, Ilya I. Ashchepkov wrote: Is spaces is necessary in text presentation of JSONB? In my data resulting text contains ~12% of spaces. can you show us an example of this? -- john r pierce 37N 122W somewhere on the middle of the left

Re: [GENERAL] JSONB spaces in text presentation

I'm sorry about sending email several times. I haven't understand, was it sent by gmail or not. On Wed, Sep 24, 2014 at 2:30 PM, John R Pierce pie...@hogranch.com wrote: On 9/24/2014 12:23 AM, Ilya I. Ashchepkov wrote: Is spaces is necessary in text presentation of JSONB? In my data

Re: [GENERAL] JSONB spaces in text presentation

On Wed, Sep 24, 2014 at 2:44 AM, Ilya I. Ashchepkov koc...@gmail.com wrote: I'm sorry about sending email several times. I haven't understand, was it sent by gmail or not. On Wed, Sep 24, 2014 at 2:30 PM, John R Pierce pie...@hogranch.com wrote: On 9/24/2014 12:23 AM, Ilya I. Ashchepkov

Re: [GENERAL] JSONB spaces in text presentation

On 09/24/2014 12:44 AM, Ilya I. Ashchepkov wrote: I'm sorry about sending email several times. I haven't understand, was it sent by gmail or not. On Wed, Sep 24, 2014 at 2:30 PM, John R Pierce pie...@hogranch.com mailto:pie...@hogranch.com wrote: On 9/24/2014 12:23 AM, Ilya I. Ashchepkov

Re: [GENERAL] JSONB spaces in text presentation

This is interesting. Most binary encoding methods I use produce smaller files than the text files for the same content. Having read your mail, I've realized that I have no reason to accept the same from the jsonb. I did a quick google search to see if it is wrong to expect binary encoding to

Re: [GENERAL] JSONB spaces in text presentation

On 09/24/2014 07:22 AM, Seref Arikan wrote: This is interesting. Most binary encoding methods I use produce smaller files than the text files for the same content. Having read your mail, I've realized that I have no reason to accept the same from the jsonb. I did a quick google search to see if

Re: [GENERAL] JSONB spaces in text presentation

IMHO, prettification is useful only for debugging. It would be nice to have a session variable for the debug output with spaces, new lines and indentation. On Wed, Sep 24, 2014 at 8:44 PM, Merlin Moncure mmonc...@gmail.com wrote: On Wed, Sep 24, 2014 at 2:44 AM, Ilya I. Ashchepkov

Re: [GENERAL] JSONB spaces in text presentation

With the same data: # create cast (jsonb as bytea) without function; # select sum(length(data::text))::float/sum(octet_length((data::jsonb)::bytea)) from data.packets; ?column? --- 0.630663654967513 and 0.554666142734544 without spaces On Wed, Sep 24, 2014 at 9:22 PM,

Re: [GENERAL] JSONB spaces in text presentation

Check slides 17-20 of http://www.sai.msu.su/~megera/postgres/talks/hstore-dublin-2013.pdf to understand, what 'binary format' means. The slides describes binary storage for nested hstore, not jsonb, but you'll get the idea. On Wed, Sep 24, 2014 at 6:22 PM, Seref Arikan serefari...@gmail.com

Re: [GENERAL] JSONB spaces in text presentation

On 9/24/2014 7:22 AM, Seref Arikan wrote: This is interesting. Most binary encoding methods I use produce smaller files than the text files for the same content. '1' vs INTEGER 1 ... 1 byte vs 4 bytes. now add metadata necessary to represent the original json structure. -- john r pierce

Re: [GENERAL] JSONB spaces in text presentation

Thanks Oleg, I'll check the slides. On Wed, Sep 24, 2014 at 8:07 PM, Oleg Bartunov obartu...@gmail.com wrote: Check slides 17-20 of http://www.sai.msu.su/~megera/postgres/talks/hstore-dublin-2013.pdf to understand, what 'binary format' means. The slides describes binary storage for nested

[GENERAL] JSONB spaces in text presentation

Hi. Is spaces is nessesary in text presentation of JSONB? In my data resulting text contains ~12% of spaces. I'm developing web application, and want to get json-string from pg and send it to browser without repacking. -- С уважением, Ащепков Илья koc...@gmail.com

Re: [GENERAL] jsonb and comparison operators

jsquery (https://github.com/akorotkov/jsquery) should works for you. On Wed, Sep 3, 2014 at 8:38 AM, Joe Van Dyk j...@tanga.com wrote: Is it possible to get this query (or a similar one) to use an index? I want to return all rows that have a value of less than 10. I have arbitrary keys I

[GENERAL] jsonb and comparison operators

Is it possible to get this query (or a similar one) to use an index? I want to return all rows that have a value of less than 10. I have arbitrary keys I want to check (not just 'a'). drop table if exists test; create table test (j jsonb); insert into test select json_build_object('a',

Re: [GENERAL] jsonb and comparison operators

On Tue, Sep 2, 2014 at 9:38 PM, Joe Van Dyk j...@tanga.com wrote: I want to return all rows that have a value of less than 10. I have arbitrary keys I want to check (not just 'a'). If you created an expression B-Tree index on 'a' it would work for 'a', but you'd have to use a jsonb literal,

Re: [GENERAL] jsonb and comparison operators

On Tue, Sep 2, 2014 at 9:55 PM, Peter Geoghegan peter.geoghega...@gmail.com wrote: On Tue, Sep 2, 2014 at 9:38 PM, Joe Van Dyk j...@tanga.com wrote: I want to return all rows that have a value of less than 10. I have arbitrary keys I want to check (not just 'a'). If you created an

[GENERAL] JsonB Gin Index is very large; is there a work around?

Hi, I'm using 9.4 beta 2. I ran a test using 4 of the largest Json docs from our production data set. The four files total to 59.4 MB of raw json, which is compressed by TOAST to 21 MB, which is great. The index, though, is 47 MB, bringing the total size of the data in PG to 68 MB. The index was

Re: [GENERAL] JsonB Gin Index is very large; is there a work around?

On Wed, Aug 20, 2014 at 1:53 PM, Larry White ljw1...@gmail.com wrote: Is there anyway to index a subset of the data in a JSONB column? I'm thinking of something like declaring certain paths to be indexed? Yes. See the expression index example in the jsonb documentation. -- Regards, Peter

Re: [GENERAL] JsonB Gin Index is very large; is there a work around?

Ok Thank you. FWIW, the documents (which I can't share) consist mainly of a long list of integers in the form {n:41515920318427252715}, so they really are outliers. On Wed, Aug 20, 2014 at 5:09 PM, Peter Geoghegan peter.geoghega...@gmail.com wrote: On Wed, Aug 20, 2014 at 1:53 PM, Larry

[GENERAL] jsonb creation functions?

There is a set of creation functions for json, such as: to_json(anyelement) There doesn't seem to be any equivalent functions for converting text to jsonb. Is there a way to do this? Thanks.

Re: [GENERAL] jsonb creation functions?

Hi, There is a set of creation functions for json, such as: to_json(anyelement) There doesn't seem to be any equivalent functions for converting text to jsonb. Is there a way to do this? You can always cast json to jsonb: test_db=# create table t (a integer primary key, b jsonb);

[GENERAL] JSONB in-place updates?

Are there any plans to add in-place at-depth update operator for JSONB type, e.g.: UPDATE test SET attrs-'anwser' = 42 where attrs-'answer' = 41