Re: PostgreSQL 10.0 SELECT LIMIT performance problem

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

In response to

Responses

Browse pgsql-bugs by date

  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.