Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)
От | Andrew Dunstan |
---|---|
Тема | Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation) |
Дата | |
Msg-id | 534475B7.6020908@dunslane.net обсуждение исходный текст |
Ответ на | Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation) (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)
Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation) |
Список | pgsql-hackers |
On 04/08/2014 05:57 PM, Peter Geoghegan wrote: > On Tue, Apr 8, 2014 at 2:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Well, let me see if I understand the situation correctly: >> >> * jsonb_ops supports more operators >> >> * jsonb_hash_ops produces smaller, better-performing indexes >> >> * jsonb_ops falls over on inputs with wide field values, but >> jsonb_hash_ops does not > There might be some compelling cases for indexing existence rather > than containment, since the recheck flag isn't set there, but in > general this summary seems sound. I would say that broadly, existence > is a less useful operator than containment, and so jsonb_hash_ops is > broadly more compelling. I didn't propose changing the default due to > concerns about the POLA, but I'm happy to be told that those concerns > were out of proportion to the practical benefits of a different > default. > I tend to agree with Tom that POLA will be more violated by the default ops class not being able to index some values. cheers andrew
В списке pgsql-hackers по дате отправления: