Re: BUG #16183: PREPARED STATEMENT slowed down by jit

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Christian Quest <cquest(at)cquest(dot)org>
Cc: github(at)cquest(dot)org, pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #16183: PREPARED STATEMENT slowed down by jit
Date: 2020-01-03 14:50:33
Message-ID: CAMkU=1zEX+kKqV9t_ZP9a+bQ=51koTfYm1qRqBuGkcx5BEuHaw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Jan 2, 2020 at 5:03 PM Christian Quest <cquest(at)cquest(dot)org> wrote:

> osm=# explain analyze execute mark_ways_by_node(1836953770);
>
> QUERY
> PLAN
>
> --------------------------------------------------------------------------------------------------------------------------------------
> Bitmap Heap Scan on planet_osm_ways (cost=2468.37..305182.32 rows=301467
> width=8) (actual time=0.039..0.042 rows=2 loops=1)
> Recheck Cond: (nodes && '{1836953770}'::bigint[])
>
I think your estimation here is falling victim to an deficiency in how
stats are computed on array types when all values in the array (across all
rows) are rare. See the discussion of this at
https://www.postgresql.org/message-id/flat/CAMkU%3D1x2W1gpEP3AQsrSA30uxQk1Sau5VDOLL4LkhWLwrOY8Lw%40mail.gmail.com

(My quick and dirty patch posted there still compiles and works, if you
would like to test that it fixes the problem for you.)

Because the number of rows is vastly overestimated, so is the cost. Which
then causes JIT to kick in counter-productively, due to the deranged cost
exceeding jit_above_cost.

Cheers,

Jeff

>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Zhihong Zhang 2020-01-03 15:29:04 Re: Indexing on JSONB field not working
Previous Message Jeff Janes 2020-01-03 14:14:48 Re: Indexing on JSONB field not working