Re: PostgreSQL 10.0 SELECT LIMIT performance problem

Поиск
Список
Период
Сортировка
От Victor Yegorov
Тема Re: PostgreSQL 10.0 SELECT LIMIT performance problem
Дата
Msg-id CAGnEbohCdScdyjtSEPpWWa8CnVzc4NKBisDAFPEoxo9QWxhCOA@mail.gmail.com
обсуждение исходный текст
Ответ на RE: PostgreSQL 10.0 SELECT LIMIT performance problem  (Mareks Kalnačs <Mareks.Kalnacs@datakom.lv>)
Ответы Re: PostgreSQL 10.0 SELECT LIMIT performance problem
RE: PostgreSQL 10.0 SELECT LIMIT performance problem
Список pgsql-bugs
ср, 12 сент. 2018 г. в 19:21, Mareks Kalnačs <Mareks.Kalnacs@datakom.lv>:

I will disagree with you about bug. I understand that foreign keys will solve some issues and we already making changes add FK, but this only bypass problem, not solve it and in different conditions we got problem again. Main issue, optimizer not take in account index distribution. In current case main cause actually is subselect. I little bit played around with indexes and different select conditions and got very strange behavior. What we done, add new index for tvc_entity table (idx_tvc_entity_sid_u) and run full analyze for all tables and got problem in reverse, now optimizer thinks that he will get less rows from subselect.


The fact, that planner is not accurate on the estimates of JSON internal keys is expected, PostgreSQL is not parsing JSON values when gathering stats.
You cannot expect planner to be picky about all possible corner cases, it would make planning time enormously huge.
That is the reason I outlined, that important keys should be extracted into plain columns.

If you still consider this is a bug, please — send isolated reproducible test case that demonstrates the bug.

--
Victor Yegorov
Вложения

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: BUG #15376: Postgres sql 9.4.19 pg_upgrade stops with error Thesource cluster was not shut down cleanly.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: PostgreSQL 10.0 SELECT LIMIT performance problem