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,
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 |