From: | Victor Yegorov <vyegorov(at)gmail(dot)com> |
---|---|
To: | Mareks(dot)Kalnacs(at)datakom(dot)lv |
Cc: | pgsql-bugs(at)postgresql(dot)org, Maris(dot)Rucis(at)datakom(dot)lv |
Subject: | Re: PostgreSQL 10.0 SELECT LIMIT performance problem |
Date: | 2018-09-12 16:43:18 |
Message-ID: | CAGnEbohCdScdyjtSEPpWWa8CnVzc4NKBisDAFPEoxo9QWxhCOA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
ср, 12 сент. 2018 г. в 19:21, Mareks Kalnačs <Mareks(dot)Kalnacs(at)datakom(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-09-12 17:04:11 | Re: PostgreSQL 10.0 SELECT LIMIT performance problem |
Previous Message | Bruce Momjian | 2018-09-12 16:41:26 | Re: BUG #15376: Postgres sql 9.4.19 pg_upgrade stops with error The source cluster was not shut down cleanly. |