Re: Calculage avg. width when operator = is missing
| От | Shulgin, Oleksandr |
|---|---|
| Тема | Re: Calculage avg. width when operator = is missing |
| Дата | |
| Msg-id | CACACo5TzCErFKsHEvqFAEa+Kv__q3ya0yGZgxb0FdTTgv+LNjQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Calculage avg. width when operator = is missing (Alvaro Herrera <alvherre@2ndquadrant.com>) |
| Список | pgsql-hackers |
On Tue, Sep 22, 2015 at 11:17 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
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.
Yes, but I didn't try this because of the requirement to compile/install/maintain the externally loadable module. If I could just use CREATE FUNCTION on a postgres' internal function such as texteq or bttextcmp (with obj_file of NULL, for example) I would definitely do that. :-)
--
Alex
В списке pgsql-hackers по дате отправления: