Re: PostgreSQL 10.0 SELECT LIMIT performance problem

From: Adrien Nayrat <adrien(dot)nayrat(at)anayrat(dot)info>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Victor Yegorov <vyegorov(at)gmail(dot)com>
Cc: <Mareks(dot)Kalnacs(at)datakom(dot)lv>, <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 17:14:34
Message-ID: 4c9ae9ac-a96b-2303-7515-4d3d89eb336e@anayrat.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 9/12/18 7:04 PM, Tom Lane wrote:
> Victor Yegorov <vyegorov(at)gmail(dot)com> writes:
>> 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.
> Right. The fact that it doesn't make the right guesses without help
> can't be considered to be a bug in all cases. These are engineering
> tradeoffs we have to make.
>
>> That is the reason I outlined, that important keys should be extracted into
>> plain columns.
> If that seems infeasible from an application standpoint, another
> possibility is to make expression indexes on those important keys.
> ANALYZE will gather stats on the values of indexed expressions, and then
> perhaps the planner will have enough info to make better decisions.

Hi,

For what it can help, I wrote this article explaining that:
https://blog.anayrat.info/en/2017/11/26/postgresql---jsonb-and-statistics/

Regards,

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Alexander Lakhin 2018-09-12 17:20:24 Re: BUG #15349: "make installcheck -C src/interfaces/libpq" fails
Previous Message Tom Lane 2018-09-12 17:04:11 Re: PostgreSQL 10.0 SELECT LIMIT performance problem