Re: Re: [SQL] querying with index on jsonb slower than standard column. Why?
От | Andrew Dunstan |
---|---|
Тема | Re: Re: [SQL] querying with index on jsonb slower than standard column. Why? |
Дата | |
Msg-id | 548B79E3.5070301@dunslane.net обсуждение исходный текст |
Ответ на | Re: Re: [SQL] querying with index on jsonb slower than standard column. Why? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: [SQL] querying with index on jsonb slower than standard column. Why?
|
Список | pgsql-performance |
On 12/12/2014 04:44 PM, Tom Lane wrote: > Josh Berkus <josh@agliodbs.com> writes: >> Yeah, I believe the core problem is that Postgres currently doesn't have >> any way to have variadic return times from a function which don't match >> variadic input types. Returning a value as an actual numeric from JSONB >> would require returning a numeric from a function whose input type is >> text or json. So a known issue but one which would require a lot of >> replumbing to fix. > Well, it'd be easy to fix if we were willing to invent distinct operators > depending on which type you wanted out (perhaps ->> for text output as > today, add ->># for numeric output, etc). That was my immediate reaction. Not sure about the operator name. I'd tentatively suggest -># (taking an int or text argument) and #># taking a text[] argument, both returning numeric, and erroring out if the value is a string, boolean, object or array. > Doesn't seem terribly nice > from a usability standpoint though. > > The usability issue could be fixed by teaching the planner to fold a > construct like (jsonb ->> 'foo')::numeric into (jsonb ->># 'foo'). > But I'm not sure how we do that except in a really ugly and ad-hoc > fashion. > > I would be inclined to add the operator and see how cumbersome people find it. I suspect in many cases it might be sufficient. cheers andrew
В списке pgsql-performance по дате отправления: