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  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Calculage avg. width when operator = is missing  ("Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>)
Список 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 по дате отправления:

Предыдущее
От: Gavin Flower
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Use gender-neutral language in documentation
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Calculage avg. width when operator = is missing