Indexing only an attribute on a json array - Postgres - arrays

Question

I have a table with a jsonb field named "data" with the following content:
{
customerId: 1,
something: "..."
list: [{ nestedId: 1, attribute: "a" }, { nestedId: 2, attribute: "b" }]
}
I need to retrieve the whole row based on its 'nestedId' attribute, note that the field is inside an array.
After checking the query plans I found out I could benefit from an index. So I added:
CREATE INDEX i1 ON mytable using gin ((data->'list') jsonb_path_ops))
From what I understood from the doc, this creates index items for the values in the "list", the solution solves my problem.
For the sake of completion follow the query I can use to retrieve my data
SELECT data FROM mytable where data->'list' #> '[{"nestedId": 1}]'
Tho, I wonder if there are more optimal indexing I could do. Is it possible to create an index only for the "nestedId" field for example?

Answer 1

You can index only the numeric values and not also the keys, using functional indexes. You probably need to make a helper function to do so.
create function jsonb_objarray_to_intarray(jsonb,text) returns int[] immutable language sql as
$$ select array_agg((x->>$2)::int) from jsonb_array_elements($1) f(x) $$;
create index on mytable using gin (jsonb_objarray_to_intarray(data->'list','nestedId'));
SELECT data FROM mytable where jsonb_objarray_to_intarray(data->'list','nestedId') #> ARRAY[3];
I wrote it this way so the function could be reused in other similar situations. If you don't care about it being re-used, you can make the code that uses it look prettier by hard coding the dereference and the key value into the function:
create function mytable_to_intarray(jsonb) returns int[] immutable language sql as
$$ select array_agg((x->>'nestedId')::int) from jsonb_array_elements($1->'list') f(x) $$;
create index on mytable using gin (mytable_to_intarray(data));
SELECT data FROM mytable where mytable_to_intarray(data) #> ARRAY[3];
Now those indexes do take longer to make than your original, but they are about half the size and are at least as fast to query. More importantly, the planner has better statistics about the selectivity, and so in more complicated queries is likely to come up with better query plans.