1. SELECT * FROM positions WHERE positions.date_stop >= CURRENT_DATE
2. Прикрепил файл
3.  Seq Scan on positions  (cost=0.00..393344.28 rows=4350685 width=605) (actual time=6.394..2061.564 rows=4350654 loops=1)
 Filter: (date_stop >= CURRENT_DATE)
 Buffers: shared hit=325406 read=2678
Planning Time: 0.217 ms
JIT:
 Functions: 2
"  Options: Inlining false, Optimization false, Expressions true, Deforming true"
"  Timing: Generation 0.871 ms, Inlining 0.000 ms, Optimization 0.467 ms, Emission 5.749 ms, Total 7.088 ms"
Execution Time: 2243.438 ms

1. Скажите... а какое слово в фразе "всё текстом" вызывает трудности в понимании?! ;)
2. А c "SET enable_seqscan = off;" что получается?
3. Это именно тот запрос, который Вам нужен (нужны именно все поля)?
4. Какая это версия PostgreSQL, сколько всего записей в таблице?

1. Сложно было уместить, отправил в личку :)
2. Index Scan using positions_date_stop_index on positions  (cost=0.43..416242.65 rows=4351441 width=605) (actual time=9.379..1451.946 rows=4351322 loops=1)
  Index Cond: (date_stop >= CURRENT_DATE)
Planning Time: 0.232 ms
JIT:
  Functions: 3
  Options: Inlining false, Optimization false, Expressions true, Deforming true
  Timing: Generation 1.135 ms, Inlining 0.000 ms, Optimization 0.643 ms, Emission 7.655 ms, Total 9.433 ms
Execution Time: 1580.917 ms
(8 rows)
3. Это пример запроса, в оригинальном 12 колонок используется.
4.  PostgreSQL 12.3,  4351324 rows

1. Цитирование же есть, или вложения. Я тут опубликую:

2. Ну и этот запрос оценивается дороже, чем seq.scan. Так что, если у Вас PostgreSQL настроен правильно (cost parameters), то план выбирается правильный. Кстати, почему опять без BUFFERS?
4. Вы уверены? Так получается, что выбирается ≈ 99.9999% таблицы... и Вы хотите использования индекса? ;)

Index Scan using positions_date_stop_index on positions  (cost=0.43..416250.04 rows=4351520 width=605) (actual time=4.252..2288.090 rows=4351357 loops=1)
  Index Cond: (date_stop >= CURRENT_DATE)
  Buffers: shared hit=325985 read=13495 dirtied=2
Planning Time: 7.308 ms
JIT:
  Functions: 3
  Options: Inlining false, Optimization false, Expressions true, Deforming true
  Timing: Generation 0.315 ms, Inlining 0.000 ms, Optimization 0.326 ms, Emission 3.698 ms, Total 4.339 ms
Execution Time: 2497.530 ms
(9 rows)

2. При сравнивание на равенство индекс срабатывает, но при сравнивание больше либо равно используется seq scan

С виду, PostgreSQL совершенно прав — индекс тут бесполезен (вреден). При его использовании даже "чтений" больше.
Т.е. никакой проблемы тут нет.

Возможно это оптимальный вариант, но данные имеют особенность рости

привет всем

Беда с одной командой - osmconvert Error: block raw size expected at: 0x0A.

osmconvert --out-statistics nenets.osm.pbf

И?

osmium fileinfo -e -g data.bbox nenets.osm.pbf - отлично отрабатывает

файл открыть можно без проблем

куда можно посмотреть?

Тут где-то был ещё чат по postgis (тут, вроде, давали ссылки на него — поищите в истории чата), попробуйте спросить ещё там.

чирс

🖤🖤🖤Are girls http://surl.li/dubc

/report

@alexls_bulgakov: @afiskon @confguru @Komzpa @pasha_golub @obartunov