Re: BUG #13874: The index of a json field which is created after data are inserted doesn't work.
В списке pgsql-bugs по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: BUG #13874: The index of a json field which is created after data are inserted doesn't work. |
| Дата | |
| Msg-id | 29066.1453176911@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: BUG #13874: The index of a json field which is created after data are inserted doesn't work. (Michael Paquier <michael.paquier@gmail.com>) |
| Список | pgsql-bugs |
Michael Paquier <michael.paquier@gmail.com> writes:
> On Mon, Jan 18, 2016 at 9:39 PM, <hukim99@gmail.com> wrote:
>> The only difference between two instructions above is whether the index is
>> created before or after data insertion. Isn't it a bug?
> My guess is that there are invalid statistics on this table. If you
> run ANALYZE on json_test you should be able to see a sequential scan
> in the first case as well. It is weird that the planner chooses a
> bitmap scan in the first case for one tuple.
Yes, after an ANALYZE you'd get the same plan either way. The difference
in behavior here is because you get sort of a half-baked ANALYZE
(specifically, an update in the table's recorded tuple count) at the time
of CREATE INDEX. I don't think this is a bug; and I note that for this
size of table, it really hardly matters which plan the planner chooses.
regards, tom lane
В списке pgsql-bugs по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера