Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)
От | Robert Haas |
---|---|
Тема | Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation) |
Дата | |
Msg-id | CA+TgmoZucoe-w5P_16A-gdfRBFCCu7PD17YO-KqrYPBhb5TxAA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation) (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)
|
Список | pgsql-hackers |
On Wed, Apr 9, 2014 at 2:37 AM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > Both of the operator classes are actually much less flexible than I'd like. > Firstly, they index everything. In many cases, that's not what you want, so > you end up with much larger indexes than necessary. Secondly, jsonb_ops > indexes all values separately from the keys. That makes the index pretty > much useless for a query on, say, WHERE json @> '{"needs_processing":true}', > if all the rows also contain a key-value pair "active":true. Thirdly, > inequality operators are not supported; you can't search for rows with (the > json-syntax equivalent of) "price < 12.3". Fourthly, sometimes you would > want to include the "path" to an entry in the key, sometimes not. Maybe we should make *neither* of these the default opclass, and give *neither* the name json_ops. > ISTM we need a way to parameterize opclasses, so that when you create the > index, you specify the above things. Yeah, that would be great. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: