Re: Calculage avg. width when operator = is missing
От | Alvaro Herrera |
---|---|
Тема | Re: Calculage avg. width when operator = is missing |
Дата | |
Msg-id | 20150922211733.GI295765@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Calculage avg. width when operator = is missing ("Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>) |
Ответы |
Re: Calculage avg. width when operator = is missing
Re: Calculage avg. width when operator = is missing |
Список | pgsql-hackers |
Shulgin, Oleksandr wrote: > On Sep 22, 2015 8:58 PM, "Andrew Dunstan" <andrew@dunslane.net> wrote: > > Yes, "/revenons/ à /nos moutons/." You can set up text based comparison > > ops fairly easily for json - you just need to be aware of the limitations. > > See https://gist.github.com/adunstan/32ad224d7499d2603708 > > Yes, I've already tried this approach and have found that analyze > performance degrades an order of magnitude due to sql-level function > overhead and casts to text. In my tests, from 200ms to 2000ms with btree > ops on a default sample of 30,000 rows. You should be able to create a C function json_cmp() that simply calls bttextcmp() internally, and C functions for each operator using that one, in the same way. In any case I think your patch is a good starting point. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: