Разный план запроса в консоли и JDBC

@bsd9 · Регистрация: 01.12.2014

Студворк — интернет-сервис помощи студентам

Добрый день!

Столкнулся с такой ситуацией, использую Postgresql PRO Ent 11.7
Есть запрос вида:

Кликните здесь для просмотра всего текста

SQL
1
2
3
4
5
6
7
8
9
10
Query Text: SELECT
      r.responsible AS id,
      COUNT(r.id) AS cnt,
      p.SURNAME,
      p.FIRSTNAME,
      p.SECONDNAME
     FROM REQUEST_TS_BASE r, PERSONAL p
     WHERE r.responsible IS NOT NULL AND p.id = r.responsible
     AND date_create >= '2022-12-31 19:00:00' AND date_create < '2023-12-31 19:00:00' AND r.id = any('{1445676,2005965,1558799,3178358,2688769,3613847,1654670,1243961,4076924,1557747,3816562,1351386,3719429,1558772,1559009,3816365,1409618,3003452,1156564,1129917,1446738,1558038,2611623,4455401,3179253,2696200,1156211,1415178,1156739,1139261,3616324,3631981,2854250,2699857,2579012,4198451,1654609,3102654,1689433,1689618,2688690,2612032,2611624,2579130,2926670,2688670,4198930,2688570,1815214,2688749,1106992,2579131,3178612,4451359,2611498,1345194,2688395,1345575,1345531,1345594,1815951,1244481,1346039,1345592,1345191,1190994,1345189,1345899,2926931,1345567,1345623,1345209,1345624,1346017,2612309,1345208,1345859,1345173,1345566,2927669,1345857,1345515,1345416,4199106,1345799,1345136,1345743,1942594,3003034,2178371,1344914,1344911,4197454,2688396,3916532,1345246,4454321,1690229,2773518,2688613,1345092,1345493,1345421,1345506,1345563,1345407,1345312,1347598,1244045,4199007,1142698,2006141,2688571,1445046,1156212,1654729,2853497,2688630,1227817,2120332,4078728,4199867,4199628,4154652,4197758,2688710,3814336,3816585,1227897,4454341,1429997,4452549,3179153,3622910,4321704,4198515,4451016,1430017,4197372,1690091,1815067,3038269,2229894,4197455,4454461,4200281,4198186,1689143,3002976,2688614,1541430,4199292,3501629,4197814,4199215,1155129,2688731,2006638,3179494,1193118,4198154,4198810,4157643,4199587,4153752,4048981,4320677,4198674,1228577,3002551,1154763,4197495,4081742,2230592,3501669,2927530,4198859,1448677,4199844,1244462,1154668,1155106,2328214,4199707,3620089,1347725,1156543,1816191,2129450,3720068,2688770,3002472,4198931,2834229,1348197,1244722,1466527,3614964,1448517,1138220,2688713,3091561,2927569,1244840,2688810,3039291,1348001,2773448,2688594,1690111,3816209,1191129,3177463,1244918,1348081,2229371,2688572,1245041,4199629,2927829,4198450,1245138,4199890,1347962,3349656,2611707,1690210,2688451,4197496,3613074,3003552,3093031,2927869,1448737,3632267,4199039,4200301,4155445,4200123,1348060,1244030,1244542,2853693,2926814,1655389,1154845,1155209,1244666,2229418,2008469,2695484,2688714,1448258,1655390,2120393,4200124,1154762,1155244}') AND r.id_org_user_create IN (SELECT /* CACHE(org_access) */ child_org_id FROM org_access WHERE org_access.parent_org_id=378692118) GROUP BY r.responsible, p.FIRSTNAME, p.SECONDNAME, p.SURNAME
ORDER BY cnt DESC

Если запускать запрос из консоли, отрабатывает быстро, его план:

Кликните здесь для просмотра всего текста

Code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
Sort (cost=126642.57..126999.36 rows=142716 width=37) (actual time=718.624..718.639 rows=187 loops=1)"
  Sort Key: (count(r.id)) DESC"
  Sort Method: quicksort  Memory: 40kB"
  Buffers: shared hit=706513"
  ->  HashAggregate  (cost=109429.04..110856.20 rows=142716 width=37) (actual time=717.431..718.546 rows=187 loops=1)"
        Group Key: r.responsible, p.firstname, p.secondname, p.surname"
        Buffers: shared hit=706513"
        ->  Hash Join  (cost=698.81..107645.09 rows=142716 width=33) (actual time=58.843..650.963 rows=166253 loops=1)"
              Hash Cond: (r.id_org_user_create = org_access.child_org_id)"
              Buffers: shared hit=706513"
              ->  Hash Join  (cost=428.17..105412.10 rows=142716 width=37) (actual time=58.314..612.017 rows=166253 loops=1)"
                    Hash Cond: (r.responsible = p.id)"
                    Buffers: shared hit=706488"
                    ->  Index Scan using request_ts_base_pk on request_ts_base r  (cost=0.43..104593.40 rows=148869 width=12) (actual time=53.924..558.704 rows=177075 loops=1)"
                          Index Cond: (id = ANY ('{1445676,2005965,1558799,3178358,2688769,3613847,1654670,1243961,4076924,1557747,3816562,1351386,3719429,1558772,1559009,3816365,1409618,3003452,1156564,1129917,1446738,1558038,2611623,4455401,3179253,2696200,1156211,1415178,1156739,1139261,3616324,3631981,2854250,2699857,2579012,4198451,1654609,3102654,1689433,1689618,2688690,2612032,2611624,2579130,2926670,2688670,4198930,2688570,1815214,2688749,1106992,2579131,3178612,4451359,2611498,1345194,2688395,1345575,1345531,1345594,1815951,1244481,1346039,1345592,1345191,1190994,1345189,1345899,2926931,1345567,1345623,1345209,1345624,1346017,2612309,1345208,1345859,1345173,1345566,2927669,1345857,1345515,1345416,4199106,1345799,1345136,1345743,1942594,3003034,2178371,1344914,1344911,4197454,2688396,3916532,1345246,4454321,1690229,2773518,2688613,1345092,1345493,1345421,1345506,1345563,1345407,1345312,1347598,1244045,4199007,1142698,2006141,2688571,1445046,1156212,1654729,2853497,2688630,1227817,2120332,4078728,4199867,4199628,4154652,4197758,2688710,3814336,3816585,1227897,4454341,1429997,4452549,3179153,3622910,4321704,4198515,4451016,1430017}'::integer[]))"
                          Filter: ((responsible IS NOT NULL) AND (date_create >= '2022-12-31 19:00:00'::timestamp without time zone) AND (date_create < '2023-12-31 19:00:00'::timestamp without time zone))"
                          Rows Removed by Filter: 3997"
                          Buffers: shared hit=706259"
                    ->  Hash  (cost=317.33..317.33 rows=8833 width=29) (actual time=4.291..4.291 rows=9086 loops=1)"
                          Buckets: 16384  Batches: 1  Memory Usage: 700kB"
                          Buffers: shared hit=229"
                          ->  Seq Scan on personal p  (cost=0.00..317.33 rows=8833 width=29) (actual time=0.012..1.986 rows=9086 loops=1)"
                                Buffers: shared hit=229"
              ->  Hash  (cost=263.13..263.13 rows=601 width=4) (actual time=0.515..0.515 rows=643 loops=1)"
                    Buckets: 1024  Batches: 1  Memory Usage: 31kB"
                    Buffers: shared hit=25"
                    ->  HashAggregate  (cost=257.12..263.13 rows=601 width=4) (actual time=0.333..0.410 rows=643 loops=1)"
                          Group Key: org_access.child_org_id"
                          Buffers: shared hit=25"
                          ->  Bitmap Heap Scan on org_access  (cost=7.47..255.51 rows=643 width=4) (actual time=0.045..0.193 rows=643 loops=1)"
                                Recheck Cond: (parent_org_id = 378692118)"
                                Heap Blocks: exact=22"
                                Buffers: shared hit=25"
                                ->  Bitmap Index Scan on org_access_parent_org_id_idx  (cost=0.00..7.31 rows=643 width=0) (actual time=0.035..0.035 rows=643 loops=1)"
                                      Index Cond: (parent_org_id = 378692118)"
                                      Buffers: shared hit=3"

Но если запрос приходит с бекенда, время выполнения его сильно увеличивается и план другой:

Кликните здесь для просмотра всего текста

Code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
 plan:
    Query Text: select
      r.responsible as id,
      count(r.id) as cnt,
      p.SURNAME,
      p.FIRSTNAME,
      p.SECONDNAME
     from REQUEST_TS_BASE r, PERSONAL p
     where r.responsible is not null and p.id = r.responsible
     and date_create >= $1 and date_create < $2 and r.id = any($3) and r.id_org_user_create in (select /* CACHE(org_access) */ child_org_id from org_access where org_access.parent_org_id=$4) group by r.responsible, p.FIRSTNAME, p.SECONDNAME, p.SURNAME
     order by cnt desc
    Sort  (cost=253016690.89..253019253.68 rows=1025117 width=37) (actual time=4904336.094..4904336.118 rows=187 loops=1)
      Sort Key: (count(r.id)) DESC
      Sort Method: quicksort  Memory: 40kB
      Buffers: shared hit=1129008
      ->  GroupAggregate  (cost=252863090.65..252888718.58 rows=1025117 width=37) (actual time=4904295.164..4904336.005 rows=187 loops=1)
            Group Key: r.responsible, p.firstname, p.surname, p.secondname
            Buffers: shared hit=1129008
            ->  Sort  (cost=252863090.65..252865653.45 rows=1025117 width=33) (actual time=4904295.131..4904304.178 rows=166253 loops=1)
                  Sort Key: r.responsible, p.firstname, p.surname, p.secondname
                  Sort Method: quicksort  Memory: 19209kB
                  Buffers: shared hit=1129008
                  ->  Merge Join  (cost=252674422.75..252689817.05 rows=1025117 width=33) (actual time=4904177.377..4904233.627 rows=166253 loops=1)
                        Merge Cond: (p.id = r.responsible)
                        Buffers: shared hit=1129008
                        ->  Index Scan using personal_pk on personal p  (cost=0.29..404.55 rows=8833 width=29) (actual time=0.012..4.026 rows=8934 loops=1)
                              Buffers: shared hit=2803
                        ->  Sort  (cost=252684295.02..252686968.30 rows=1069315 width=8) (actual time=4904172.602..4904197.785 rows=177016 loops=1)
                              Sort Key: r.responsible
                              Sort Method: quicksort  Memory: 14442kB
                              Buffers: shared hit=1126205
                              ->  Hash Semi Join  (cost=263.97..252577212.45 rows=1069315 width=8) (actual time=59.990..4903945.868 rows=177016 loops=1)
                                    Hash Cond: (r.id_org_user_create = org_access.child_org_id)
                                    Buffers: shared hit=1126205
                                    ->  Index Scan using request_ts_base_datecreate_org on request_ts_base r  (cost=0.43..252551552.67 rows=1069315 width=12) (actual time=59.655..4903280.547 rows=177016 loops=1)
                                          Index Cond: ((date_create >= '2022-12-31 19:00:00'::timestamp without time zone) AND (date_create < '2023-12-31 19:00:00'::timestamp without time zone))
                                          Filter: ((responsible IS NOT NULL) AND ((id)::numeric = ANY ('{1445676,2005965,1558799,3178358,2688769,3613847,1654670,1243961,4076924,1557747,3816562,1351386,3719429,1558772,1559009,3816365,1409618,3003452,1156564,1129917,1446738,1558038,2611623,4455401,3179253,2696200,1156211,1415178,1156739,1139261,3616324,3631981,2854250,2699857,2579012,4198451,1654609,3102654,1689433,1689618,2688690,2612032,2611624,2579130,2926670,2688670,4198930,2688570,1815214,2688749,1106992,2579131,3178612,4451359,2611498,1345194,2688395,1345575,1345531,1345594,1815951,1244481,1346039,1345592,1345191,1190994,1345189,1345899,2926931,1345567,1345623,1345209,1345624,1346017,2612309,1345208,1345859,1345173,1345566,2927669,1345857,1345515,1345416,4199106,1345799,1345136,1345743,1942594,3003034,2178371,1344914,1344911,4197454,2688396,3916532,1345246,4454321,1690229,2773518,2688613,1345092,1345493,1345421,1345506,1345563,1345407,1345312,1347598,1244045,4199007,1142698,2006141,2688571,1445046,1156212,1654729,2853497,2688630,1227817,2120332,4078728,4199867,4199628,4154652,4197758,2688710,3814336,3816585,1227897,4454341,1429997,4452549,3179153,3622910,4321704,4198515,4451016,1430017,4197372,1690091,1815067,3038269,2229894,4197455,4454461,4200281,4198186,1689143,3002976,2688614,1541430,4199292,3501629,4197814,4199215,1155129,2688731,2006638,3179494,1193118,4198154,4198810,4157643,4199587,4153752,4048981,4320677,4198674,1228577,3002551,1154763,4197495,4081742,2230592,3501669,2927530,4198859,1448677,4199844,1244462,1154668,1155106,2328214,4199707,3620089,1347725,1156543,1816191,2129450,3720068,2688770,3002472,4198931,2834229,1348197,1244722,1466527,3614964,1448517,1138220,2688713,3091561,2927569,1244840,2688810,3039291,1348001,2773448,2688594,1690111,3816209,1191129,3177463,1244918,1348081,2229371,2688572,1245041,4199629,2927829,4198450,1245138,4199890,1347962,3349656,2611707,1690210,2688451,4197496,3613074,3003552,3093031,2927869,1448737,3632267,4199039,4200301,4155445,4200123,1348060,1244030,1244542,2853693,2926814,1655389,1154845,1155209,1244666,2229418,2008469,2695484,2688714,1448258,1655390,2120393,4200124,1154762,1155244}') Rows Removed by Filter: 941780
                                          Buffers: shared hit=1126180
                                    ->  Hash  (cost=255.51..255.51 rows=643 width=4) (actual time=0.312..0.313 rows=643 loops=1)
                                          Buckets: 1024  Batches: 1  Memory Usage: 31kB
                                          Buffers: shared hit=25
                                          ->  Bitmap Heap Scan on org_access  (cost=7.47..255.51 rows=643 width=4) (actual time=0.052..0.226 rows=643 loops=1)
                                                Recheck Cond: (parent_org_id = 378692118)
                                                Heap Blocks: exact=22
                                                Buffers: shared hit=25
                                                ->  Bitmap Index Scan on org_access_parent_org_id_idx  (cost=0.00..7.31 rows=643 width=0) (actual time=0.031..0.031 rows=643 loops=1)
                                                      Index Cond: (parent_org_id = 378692118)
                                                      Buffers: shared hit=3

Не могу понять, почему план меняется. Я понимаю, что какие-то параметры могли быть предопределены в драйвере JDBC, но какие именно? При том, что параметры драйвера точно не трогали, а проблема эта появилась недавно.
Второе, как видно из медленного плана там очень долгий Index Scan по request_ts_base_datecreate_org. Пусть даже планировщик выбрал "ошибочный" индекс, почему он такой долгий? Размер индекса на 1 мегабайт всего лишь отличается.
Это не единственный запрос в системе с другим планом, этот более частотный.

Может есть у кого соображения на этот счет? Заранее спасибо.

@PaulWist · 31.10.2023, 13:03

В "быстром" запросе переданные значения приводятся к типу int

SQL
1
(id = ANY ('{1445676,2005965,......'::INTEGER[]))"

что позволяет использовать индекс.

В "долгом" запросе

SQL
1
r.id = any($3)

поле r.id приводится к типу numeric

SQL
1
(id)::NUMERIC

что вызывает сканирование всего индекса.

В самом запросе приведите типы данных select ..... where ..... r.id = any()::ineger

@bsd9 · 31.10.2023, 13:15 **[ТС]**

PaulWist, спасибо. Нет доступа к коду. Я могу индекс с приведем только подложить.
Непонятно только, почему он этого не делает при запуске через psql?

@PaulWist · 31.10.2023, 13:28

Начнем с того, что эти два запрос РАЗНЫЕ и сравнивать их нельзя.

Сообщение от bsd9

Непонятно только, почему он этого не делает при запуске через psql?

Возможно сначала выполняется PREPARE statment.

В "быстром" запросе в ANY лежат конкретные значение, в "долгом" приходит параметр, то есть оптимизатор не знает сколько там значений (в параметре) и какие это значения, поэтому план строится из предположения, что пришедшие в параметре значения в "среднем" укладываются в статистику.

ЗЫ запрос ORM генерит?

@bsd9 · 31.10.2023, 13:32 **[ТС]**

Сообщение от PaulWist

Начнем с того, что эти два запрос РАЗНЫЕ и сравнивать их нельзя.

Хм. Странно, сейчас перепроверю, возможно действительно не тот скопировал.

Сообщение от PaulWist

ЗЫ запрос ORM генерит?

Фреймворк какой-то самописный.

@PaulWist · 31.10.2023, 15:07

Сообщение от bsd9

возможно действительно не тот скопировал.

"Запрос" тот же, просто эти два запроса не эквивалентны (разные, по мнению оптимизатора сервера).

То есть

SQL
1
SELECT * FROM TABLE WHERE id = 1

не эквивалентен

SQL
1
SELECT * FROM TABLE WHERE id = $1

хотя на первый взгляд запросы одинаковы.

@bsd9 · 31.10.2023, 16:32 **[ТС]**

PaulWist, понял вас.

Я пока что сделаю индекс:

Кликните здесь для просмотра всего текста

SQL
1
2
3
4
5
CREATE INDEX CONCURRENTLY "request-numeric"
  ON request_ts_base(
    (id::NUMERIC), date_create)
  WHERE
    responsible IS NOT NULL;

Должно же помочь по идее?

И все равно я не до конца понимаю, в ANY что сейчас приходит параметр, что и неделю назад. Неделю назад такого поведения не было, запрос работал за секунды. Из разработки ничего не меняли говорят, или могли не осознано поменять?

@PaulWist · 31.10.2023, 16:58

Сообщение от bsd9

Должно же помочь по идее?

Приведите DDL таблиц и запрос перепишите с алиасами, что бы не догадываться откуда поле берётся.

Пальцем в небо (что бы всё взять из индекса, хотя всё равно полезет в таблицу ели карта видимости модифицирована)

SQL
1
2
3
4
5
CREATE INDEX CONCURRENTLY "request-numeric"
  ON request_ts_base(
    (id::NUMERIC), date_create, id_org_user_create, responsible )
  WHERE
    responsible IS NOT NULL;

Посмотрите как и когда на этих таблицах делался вакуум.

И ещё в план добавьте explain (...... BUFFERS) результат в студию.

@bsd9 · 31.10.2023, 17:42 **[ТС]**

Сообщение от PaulWist

и запрос перепишите с алиасами, что бы не догадываться откуда поле берётся.

Какое именно поле? Только локально могу переписать, нет доступа к коду.

Сообщение от PaulWist

Посмотрите как и когда на этих таблицах делался вакуум.

auto_vacuum и auto_analyze по табличкам которые по идее часто меняются, все за сегодня, плюс минут пару часов.
Как понять если он недостаточно часто идет?

Сообщение от PaulWist

И ещё в план добавьте explain (...... BUFFERS) результат в студию.

Так у меня же с (ANALYZE, BUFFERS, TIMING) explain запущен...

@PaulWist · 01.11.2023, 08:33

Сообщение от bsd9

Какое именно поле? Только локально могу переписать, нет доступа к коду.

В селекте укажите алиасы для date_create (подозреваю, что r.date_create).

Локально:

1. Создайте ф-ию с этим запросом и 4 параметрами

SQL
1
AND date_create >= $1 AND date_create < $2 AND r.id = any($3) AND r.id_org_user_create IN (SELECT /* CACHE(org_access) */ child_org_id FROM org_access WHERE org_access.parent_org_id=$4) GROUP BY r.responsible, p.FIRSTNAME, p.SECONDNAME, p.SURNAME

2. Получите план вызова этой ф-ии.

Сообщение от bsd9

auto_vacuum и auto_analyze по табличкам которые по идее часто меняются, все за сегодня, плюс минут пару часов.

Посмотрите поля Last_...

SQL
1
SELECT * FROM pg_stat_user_tables WHERE relname IN ('REQUEST_TS_BASE', ' PERSONAL')

Сообщение от bsd9

Так у меня же с (ANALYZE, BUFFERS, TIMING) explain запущен...

Да, пардон, глаз замылился.

Сообщение от bsd9

И все равно я не до конца понимаю, в ANY что сейчас приходит параметр, что и неделю назад. Неделю назад такого поведения не было, запрос работал за секунды. Из разработки ничего не меняли говорят, или могли не осознано поменять?

Дело в том, что план выбирается не самый оптимальный, а наилучший из тех которые оптимизатор успел построить за отведенное ему время.

Хрестоматийный пример, для поиска оптимального плана оптимизатору надо потратить 10 сек, в этом случае запрос выполнится за 1 сек, либо оптимизатор найдёт план за 1 сек, но такой запрос будет выполняться 5 сек, те в 5 раз дольше, НО суммарное время получение плана + выполнение будет в 2 раза меньше, поэтому план может быть кривой.

@bsd9 · 11.11.2023, 12:38 **[ТС]**

PaulWist, здравствуйте. После того как создал те индексы, заработало быстрее. Но тоже не особо вариант, потому что видимо из-за добавление нового индекса, апдейты стали работать медленнее.

Сообщение от PaulWist

поле r.id приводится к типу numeric

Я не понимаю, зачем вообще он это делает? Поле же int.
Или оптимизатор думает, что в этом столбце могут быть numeric значения?

@PaulWist · 13.11.2023, 08:16

Сообщение от bsd9

После того как создал те индексы, заработало быстрее. Но тоже не особо вариант, потому что видимо из-за добавление нового индекса, апдейты стали работать медленнее.

Конечно, команды DML "замедлятся", поскольку надо поддерживать индекс.

Сообщение от bsd9

Я не понимаю, зачем вообще он это делает? Поле же int.
Или оптимизатор думает, что в этом столбце могут быть numeric значения?

Ммм, приходящий параметр оптимизатор "определяет" как numeric, это первое.

Второе, существует "приоритет типов данных", то есть Если оператор сочетает выражения различных типов данных, тип данных с меньшим приоритетом сначала преобразуется в тип данных с большим приоритетом. .

В соответствии с этим, numeric "выше/приоритетнее" int, поэтому колонка таблицы приводится к numtric.

В ORM надо параметр привести к int. (если это возможно, либо поле изменить на numeric)

@bsd9 · 13.11.2023, 13:11 **[ТС]**

Сообщение от PaulWist

Ммм, приходящий параметр оптимизатор "определяет" как numeric, это первое.

В каком плане определяет? И может ли быть так, что по ошибке в параметр numeric затесался? Типа должно было быть 1001, а в параметр передали 1001.0.

Сообщение от PaulWist

существует "приоритет типов данных"

Спасибо, изучу эту тему. Надеюсь после этого станет понятно, почему несколькими неделями ранее все нормально было.

@PaulWist · 13.11.2023, 13:18

Сообщение от bsd9

В каком плане определяет?

В медленном с параметром.

SQL
1
(id)::NUMERIC

В быстром видим, что переданные значения интерпретируются как int

Сообщение от bsd9

И может ли быть так, что по ошибке в параметр numeric затесался? Типа должно было быть 1001, а в параметр передали 1001.0.

В плане этого нет, тут вопрос как драйвер интерпретирует переданный список.

@bsd9 · 13.11.2023, 16:55 **[ТС]**

Сообщение от PaulWist

В плане этого нет, тут вопрос как драйвер интерпретирует переданный список.

Это где-то почитать можно? Случай я так понимаю не очень тривиальный.

@PaulWist · 14.11.2023, 09:26

Сообщение от bsd9

то где-то почитать можно? Случай я так понимаю не очень тривиальный.

Могу только "ванговать", в ORM массив (Array) описан как setLong, setDouble, если это так, то остаётся пересоздать поле id как numeric и индексы пересоздать.

Тут про типы драйвера в Arrays

@bsd9 · 17.11.2023, 13:14 **[ТС]**

Сообщение от PaulWist

В самом запросе приведите типы данных select ..... where ..... r.id = any()::ineger

В исходном запросе не получается так сделать, массив не приводится к integer:
ERROR: argument of AND must be type boolean, not type character varying

Мне нужно запрос переписывать каким-то определенным образом или в принципе не сработает это?

@PaulWist · 17.11.2023, 13:58

Сообщение от bsd9

Мне нужно запрос переписывать каким-то определенным образом или в принципе не сработает это?

Ну, если есть доступ к фреймворк, то перепишите через временную таблицу с полем int, сначала загоните массив чисел во времянку, затем в запросе измените:

SQL
1
SELECT ..... WHERE ..... r.id = any(SELECT IntValue FROM temptable)

@bsd9 · 17.11.2023, 17:28 **[ТС]**

Сообщение от PaulWist

Ну, если есть доступ к фреймворк

Если нет, только менять тип столбца?

@PaulWist · 17.11.2023, 20:40

Да, у ПГ не такой продвинутый движок, те он не умеет делать Merge Interval.

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL3_image 8Observer8 10.02.2026 Содержание блога Библиотека SDL3_image содержит инструменты для расширенной работы с изображениями. Пошагово создадим проект для загрузки изображения формата PNG с альфа-каналом (с прозрачным. . .	Установка Qt-версии Lazarus IDE в Debian Trixie Xfce volvo 10.02.2026 В общем, достали меня глюки IDE Лазаруса, собранной с использованием набора виджетов Gtk2 (конкретно: если набирать текст в редакторе и вызвать подсказку через Ctrl+Space, то после закрытия окошка. . .	SDL3 для Web (WebAssembly): Работа со звуком через SDL3_mixer 8Observer8 08.02.2026 Содержание блога Пошагово создадим проект для загрузки звукового файла и воспроизведения звука с помощью библиотеки SDL3_mixer. Звук будет воспроизводиться по клику мышки по холсту на Desktop и по. . .	SDL3 для Web (WebAssembly): Основы отладки веб-приложений на SDL3 по USB и Wi-Fi, запущенных в браузере мобильных устройств 8Observer8 07.02.2026 Содержание блога Браузер Chrome имеет средства для отладки мобильных веб-приложений по USB. В этой пошаговой инструкции ограничимся работой с консолью. Вывод в консоль - это часть процесса. . .
SDL3 для Web (WebAssembly): Обработчик клика мыши в браузере ПК и касания экрана в браузере на мобильном устройстве 8Observer8 02.02.2026 Содержание блога Для начала пошагово создадим рабочий пример для подготовки к экспериментам в браузере ПК и в браузере мобильного устройства. Потом напишем обработчик клика мыши и обработчик. . .	Философия технологии iceja 01.02.2026 На мой взгляд у человека в технических проектах остается роль генерального директора. Все остальное нейронки делают уже лучше человека. Они не могут нести предпринимательские риски, не могут. . .	SDL3 для Web (WebAssembly): Вывод текста со шрифтом TTF с помощью SDL3_ttf 8Observer8 01.02.2026 Содержание блога В этой пошаговой инструкции создадим с нуля веб-приложение, которое выводит текст в окне браузера. Запустим на Android на локальном сервере. Загрузим Release на бесплатный. . .	SDL3 для Web (WebAssembly): Сборка C/C++ проекта из консоли 8Observer8 30.01.2026 Содержание блога Если вы откроете примеры для начинающих на официальном репозитории SDL3 в папке: examples, то вы увидите, что все примеры используют следующие четыре обязательные функции, а. . .

@bsd9 0 / 0 / 0 Регистрация: 01.12.2014 Сообщений: 118
	31.10.2023, 13:15 [ТС]
	PaulWist, спасибо. Нет доступа к коду. Я могу индекс с приведем только подложить. Непонятно только, почему он этого не делает при запуске через psql? 0

@PaulWist 668 / 291 / 120 Регистрация: 12.04.2022 Сообщений: 1,000
	17.11.2023, 20:40
	Да, у ПГ не такой продвинутый движок, те он не умеет делать Merge Interval. 1

Разный план запроса в консоли и JDBC

Решение