Re: BUG #16183: PREPARED STATEMENT slowed down by jit
От | Andres Freund |
---|---|
Тема | Re: BUG #16183: PREPARED STATEMENT slowed down by jit |
Дата | |
Msg-id | 20200102221736.t24laxhv2ruzd7us@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: BUG #16183: PREPARED STATEMENT slowed down by jit (Christian Quest <cquest@cquest.org>) |
Список | pgsql-bugs |
Hi, On 2020-01-02 22:29:31 +0100, Christian Quest wrote: > osm=# PREPARE mark_ways_by_node(bigint) AS select id from planet_osm_ways > WHERE nodes && ARRAY[$1]; > PREPARE > 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=5.775..5.905 rows=2 loops=1) > Recheck Cond: (nodes && '{1836953770}'::bigint[]) > Heap Blocks: exact=2 > -> Bitmap Index Scan on planet_osm_ways_nodes (cost=0.00..2393.00 > rows=301467 width=0) (actual time=0.512..0.512 rows=2 loops=1) > Index Cond: (nodes && '{1836953770}'::bigint[]) > Planning Time: 3.667 ms > JIT: > Functions: 4 > Options: Inlining false, Optimization false, Expressions true, Deforming > true > Timing: Generation 0.466 ms, Inlining 0.000 ms, Optimization 0.354 ms, > Emission 4.634 ms, Total 5.454 ms > Execution Time: 30.393 ms > (11 rows) I'm not too surprised heuristics down't work, if the row sestimate is off by ~5 orders of magnitude... Caching could "fix" this by making the JIT cost less noticable, but you're very liable to get bad plan decisions as long as you're that far off with estimated plan costs. Greetings, Andres Freund
В списке pgsql-bugs по дате отправления: