Re: Performance on JSONB select

Поиск
Список
Период
Сортировка
Искать
От
Stephen Frost
Тема
Re: Performance on JSONB select
Дата
Msg-id
20191002215747.GR6962@tamriel.snowman.net
Ответ на
Список
Дерево обсуждения
Performance on JSONB select PegoraroF10 <marcos@f10.com.br>
Re: Performance on JSONB select Michael Lewis <mlewis@entrata.com>
Re: Performance on JSONB select PegoraroF10 <marcos@f10.com.br>
Re: Performance on JSONB select PegoraroF10 <marcos@f10.com.br>
Re: Performance on JSONB select Pavel Stehule <pavel.stehule@gmail.com>
Re: Performance on JSONB select PegoraroF10 <marcos@f10.com.br>
Re: Performance on JSONB select Fabrízio de Royes Mello <fabrizio@timbira.com.br>
Re: Performance on JSONB select PegoraroF10 <marcos@f10.com.br>
Re: Performance on JSONB select Michael Lewis <mlewis@entrata.com>
Re: Performance on JSONB select PegoraroF10 <marcos@f10.com.br>
Re: Performance on JSONB select PegoraroF10 <marcos@f10.com.br>
Re: Performance on JSONB select Stephen Frost <sfrost@snowman.net>
Greetings,

* Michael Lewis (mlewis@entrata.com) wrote:
> Much of indexing strategy depends on knowing the data like how many
> distinct values and what the distribution is like. Is JsonBField->>'status'
> always set? Are those three values mentioned in this query common or rare?
> Can you re-write this query to avoid using an OR in the where clause? Are
> you just wanting to add a GIN index for the jsonb paths? Or do you want
> indexed like below that are a bit stylized to this query?

If you know a field is going to always be there, you're better off, by
far, by just having a regular column for that value and a straight up
btree for it.  This saves a significant amount of space and makes it
much easier to index and work with.

Thanks,

Stephen
В списке pgsql-general по дате отправления
От: Shital A
Дата:
От: Stephen Frost
Дата:
FAQ