Кстати, Вы могли бы попробовать оптимизировать этот запрос (хотя бы проверить, есть ли подходящие индексы и т.д.)

Да, держит, а что ему делать-то? Он запрос-то ещё, может, и не выполнил целиком... и, возможно, не выполнит до выдачи всех данных.

Да, держит, а что ему делать-то? Он запрос-то ещё, может, и не выполнил целиком... и, возможно, не выполнит до выдачи всех данных.

Он же перестал потреблять CPU

Естественно, если Вы читаете ~3M rows 20 минут, много он не потребит.

ходить по курсору питоном имхо моветон. в хранимке норм

ходить по курсору питоном имхо моветон. в хранимке норм

А какая разница?

А какая разница?

еще один слой, не? на самом деле я даже не представляю как это делается из питона ))

что именно?

cur.execute("declare foo cursor for select * from generate_series(1,1000000)") cur.execute("fetch forward 100 from foo") rows = cur.fetchall() # ... cur.execute("fetch forward 100 from foo") rows = cur.fetchall() # and so on

еще один слой, не? на самом деле я даже не представляю как это делается из питона ))

Я не понял про слой. Наверно потому что надо пойти таки поспать немного :D

Все равно же в хранимке тожуе будет занято много памяти.

В общем, раз Вам нужно 20 минут на обработку данных, нужна или же память для активного запроса (а сколько её будет —- зависит от work_mem); либо память только для результатов —- на клиенте (если Вы считываете всё сразу, с курсором или без, и завершаете транзакцию), или же на сервере —- если использовать WITH HOLD в курсоре.

В общем, раз Вам нужно 20 минут на обработку данных, нужна или же память для активного запроса (а сколько её будет —- зависит от work_mem); либо память только для результатов —- на клиенте (если Вы считываете всё сразу, с курсором или без, и завершаете транзакцию), или же на сервере —- если использовать WITH HOLD в курсоре.

а что делает WITH HOLD?

WITH HOLD specifies that the cursor can continue to be used after the transaction that created it successfully commits. WITHOUT HOLD specifies that the cursor cannot be used outside of the transaction that created it. If neither WITHOUT HOLD nor WITH HOLD is specified, WITHOUT HOLD is the default.

В общем, раз Вам нужно 20 минут на обработку данных, нужна или же память для активного запроса (а сколько её будет —- зависит от work_mem); либо память только для результатов —- на клиенте (если Вы считываете всё сразу, с курсором или без, и завершаете транзакцию), или же на сервере —- если использовать WITH HOLD в курсоре.

В постгресе оно все таки компактней и похоже надо в нем держать, а не на клиенте. Я думал можно как-то еще постгрес оптимизировать по памяти

Yaroslav больше спасибо за разъяснение!

In the current implementation, the rows represented by a held cursor are copied into a temporary file or memory area so that they remain available for subsequent transactions. А так, или уменьшайте work_mem, или попробуйте оптимизировать сам запрос.

Да, держит, а что ему делать-то? Он запрос-то ещё, может, и не выполнил целиком... и, возможно, не выполнит до выдачи всех данных.

он может удалять если там тупо seq scan но так как там джойны и hash, ему что ли на каждые 1000 строк строить хешь заного?

на самом деле интересный кейс

@ihor_ukraine вам бы условие какое-нибудь ввеcти и отрезать кусками, и кушать в Django.

seq scan ничего и не держит. А вот hash-и, materialize-ы и т.п. останутся с нами до победного конца. ;)

seq scan ничего и не держит. А вот hash-и, materialize-ы и т.п. останутся с нами до победного конца. ;)

в 10 вроде хотели буферизировать всплытие тюплов что бы хоть немного уменьшить кеш мисы и дать возможность использовать SIMD.

но это уже другая тема

@ihor_ukraine и не волнуйтесь на счёт ООМ киллера, постгрес умеет все действия делать на диске.

@ihor_ukraine вам бы условие какое-нибудь ввеcти и отрезать кусками, и кушать в Django.

Сейчас оно работает вот так def queryset_iterator(queryset, chunk_size=250000): """ Iterate over a Django Queryset ordered by the primary key This method loads a maximum of chunk_size (default: 1000) rows in it's memory at the same time while django normally would load all rows in it's memory. Using the iterator() method only causes it to not preload all the classes. Note that the implementation of the iterator does not support ordered query sets. """ try: last_pk = queryset.order_by('-pk')[:1].get().pk except ObjectDoesNotExist: return pk = 0 queryset = queryset.order_by('pk') while pk < last_pk: for row in queryset.filter(pk__gt=pk)[:chunk_size].iterator(): pk = row.pk yield row gc.collect()

Оно медленно и прожорливо

Я пойду посплю, перепишу на новый код и потом попробую на проде

ну вас и так не быстро идёт обработка

Основная проблема с этим решениям Note that the implementation of the iterator does not support ordered query sets.

почему индексов нету к слову?

ну вас и так не быстро идёт обработка

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

почему индексов нету к слову?

там будут данные с разными where для которых строить индексы не имееть смысла

там будут данные с разными where для которых строить индексы не имееть смысла

почему? Я про то что бы ибавиться от hash join

для join они могут огого как взлететь

"forensics_forensic"."is_archived" = False AND "forensics_forensic"."is_valid" = True вот эти значения будут постоянны, а остальные where разные могут быть

Для такого случая подойдет Partial Index?

@stalkerg спасибо за советы. Я уже завтра попробую индексы

приятных снов

приятных снов

Спасибо :D

Всем привет МОжете подскзать, почему БД себя ведет так. Есть у нас БД1. Через createdb -T создаю копию БД2. 1 к 1. Затем делаю реиндекс основных таблиц на БД2. После реиндекса - гоняю на БД2 те же запросы, что и на БД1. На БД2 - запросы висят жестко. Фуллскан идет, некоторых запросов. В субботу я оставил в покое БД2. Вчера ночью полез проверить БД2, и вуаля, запросы летают так же как и на БД1. Можете подсказать, что это может быть?

статистику собрать нужно?

собирал

надо смотреть запроссы, и explain analyze что бы понять, почему он ошибается на одной БД и не ошибается на другой

я ведь верно понял, что проблемма в том что на БД1, у вас сексканы пошли вместо индекс сканов?

но обычно тут дело в статистике и... а вы на какой БД делали реиндекс?

на БД2

БД1 вообще не трогал

я ведь верно понял, что проблемма в том что на БД1, у вас сексканы пошли вместо индекс сканов?

в том то и дело, что на БД2 не работают индексы

на БД1 я не делаю ничего

тк просто с нее создал клон БД2

ну вот explain analyze вам скажет почему

если реально индекс есть и эстиматор правильно всё предсказал то ответ должен быть достаточно очевидным

/me всё же надо добавить в SQL стандарт индексы... хотя бы как запись в лог если индекс который хотел использовать, не сработали.

нужно как то уменьшать неочевидности в исполнении SQL...

хотя бы как: select * from my_table where my_table.field1{my_index2} = 10; надо глянуть BISON, кажется эту граматику будет не трудно добавить. Ладно, это на правах бреда.

спасибо буду копать

хотя бы как: select * from my_table where my_table.field1{my_index2} = 10; надо глянуть BISON, кажется эту граматику будет не трудно добавить. Ладно, это на правах бреда.

Это hints, что ли? Или в чём тут суть?

спасибо буду копать

У Вас, скорее всего, дело в том, что на копии за ночь отработал autoanalyze.

Это hints, что ли? Или в чём тут суть?

да, хотя хотелось бы скорее жёсткое правило.

да, хотя хотелось бы скорее жёсткое правило.

Надеюсь, это никогда не добавят. Особенно в стандарт.

хинты это плохо

Надеюсь, это никогда не добавят. Особенно в стандарт.

почему? Я ххочу прозрачности исполнения со стороны языка запросов

может SQL2

У Вас, скорее всего, дело в том, что на копии за ночь отработал autoanalyze.

спасибо, проверю

А я совсем не хочу. Зачем это надо? Я хочу, чтобы результаты были верные, по возможности, быстро.

может SQL2

Может SQL/2? ;)

Может SQL/2? ;)

давайте так :)

А я совсем не хочу. Зачем это надо? Я хочу, чтобы результаты были верные, по возможности, быстро.

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

Ну уж индексные hint в таких случаях довольно плохо подходят (и мало в каких подходят вообще, IMHO). Вот cardinality hints, возможно, были бы интересны.

Ну уж индексные hint в таких случаях довольно плохо подходят (и мало в каких подходят вообще, IMHO). Вот cardinality hints, возможно, были бы интересны.

я скорее думаю про валидацию сценария исполнения, что бы понять, что что то работает не так как надо

Хмм... в смысле?

т.е. если твоё приложение закладывается на использование индексов, хочется как то узнать, что кто то напортачил и они не используются.

ну т.е. не будешь же ты вручную эксплейны отсматривать (а на пустой БД вообще мало смысла), или логи?

т.е. по сути юнит тест для БД

Почему закладывается-то? По каким причинам?

ну когда ты 100% знаешь что тут должна быть индексная выборка и она 100% быстрее секскана

И зачем EXPLAIN-ы отсматривать?

потому что лезешь с эксплейном уже тогда когда что то тормозит....

Никто этого почти никогда не знает. На то и оптимизаторы. Т.е. это вообще не аргумент. :(

доброе утро) вопрос про оптимальный алгоритм) задача - есть таблица model, там поля id, date_modified (Python, Django, date_modified = models.DateTimeField(_('date modified'), auto_now=True), там дата изменения документа с микросекундами, которые стоит игнорить), есть некий список словарей на питоне [{‘id’: 1, ‘date_modified’: 1508817032}, …], тут unixtimestamp в секундах, задача - написать, какие id из этого списка имеют отличные date_modified от СУБД, то есть сделать список id изменённых документов допустим, в списке 100 000 пар объектов, как лучше сделать - выгрузить все данные одним запросом и на питоне сравнивать или делать кучу запросов к базе? или какой-нибудь третий вариант (один неведомый запрос к базе)?

Подготовить эти данные фоновым процессом никак не связанным с работой веб сервера.

Почему закладывается-то? По каким причинам?

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

Так если оптимизатор их не использует, в 99% случаев дело-то в том... что разработчику казалось неправильно. ;)

на схему данных смотрел, грибы кушал, потребности фронта осознал, создал охватывающий индекс, а он бац и не юзается. потому что оптимизатор умнее тебя оказался. ну, такое себе

на схему данных смотрел, грибы кушал, потребности фронта осознал, создал охватывающий индекс, а он бац и не юзается. потому что оптимизатор умнее тебя оказался. ну, такое себе

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

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

А если вставка по несколько тысяч операций в секунду?

на схему данных смотрел, грибы кушал, потребности фронта осознал, создал охватывающий индекс, а он бац и не юзается. потому что оптимизатор умнее тебя оказался. ну, такое себе

Самое обидное не так ). Самое обидное - когда индекс привлекателен (оптимизатор использует), но с накоплением данных селективность падает и он остаётся висеть мертвым грузом

А если вставка по несколько тысяч операций в секунду?

То... что? Т.е. в чём вопрос-то?

Самое обидное не так ). Самое обидное - когда индекс привлекателен (оптимизатор использует), но с накоплением данных селективность падает и он остаётся висеть мертвым грузом

А это, по идее, довольно редкая ситуация, разве нет?

То... что? Т.е. в чём вопрос-то?

Индексы замедляют вставку... Причем составные - сильно замедляют. Неиспользуемые индексы - непозволительная роскошь)

Индексы замедляют вставку... Причем составные - сильно замедляют. Неиспользуемые индексы - непозволительная роскошь)

Ну и что, что замедляют? Я, кстати, не зря коварно написал: "должны подходить для "критичных" запросов". ;) А я думаю, что позволительная. Т.е. пока производительность достаточна, всем как-то (должно быть) всё равно.

@pasha_golub @Komzpa вы в доле?))

А это, по идее, довольно редкая ситуация, разве нет?

Частая. Особенно для новых систем. На этапе разработки невозможно учесть специфики данных. Допустим мы храним историю изменений в той же таблице и предполагаем, что изменений будет достаточно много - строим индекс с доп полем is_actual - и на начальном этапе - все тыркаются вносят/правят данные... Достаточно много как актуальных так и исторических данных... Индекс сразу фильтрует большую часть записей по признаку актуальности. Потом пользователи "освоились" и практически всегда вносят данные без ошибок... У нас доля актуальных растёт и индекс становится не привлекательным... мертвым

А так да... Я сам делаю так - строю индексы под все тяжёлые запросы в системе... Потом выделяю общие из них... Убираю неиспользуемые... Часть переделываю в частичные (как раз для is_actual)...

Ребят, никто не будет против, если я добавлю чатик в https://github.com/mr-mig/ru-tech-chats ?

возможно это было ошибкой ?