ну и где он хранится?

я бы work_mem увеличил для запроса, например, до 512 мб

ну и где он хранится?

Нигде. В том и дело.

он хранится в памяти клиента

если памяти не хватает, то либо клиент подвисает, либо запрос завершается с ошибкой

он хранится в памяти клиента

Это ПОСЛЕ передачи клиенту. Это да, как клиент хочет...

а ДО передачи клиенту где? Нигде. В том и дело. и Как сам думаешь, СУБД имеет память чтобы хранить твои эти 1.1. млн записей? значит проблемы нет вообще, запрос сразу передается клиенту без промежуточного хранения

а ДО передачи клиенту где? Нигде. В том и дело. и Как сам думаешь, СУБД имеет память чтобы хранить твои эти 1.1. млн записей? значит проблемы нет вообще, запрос сразу передается клиенту без промежуточного хранения

Что ты понимаешь под "запрос" ? Запрос вообще-то клиент серверу повылает...

а ДО передачи клиенту где? Нигде. В том и дело. и Как сам думаешь, СУБД имеет память чтобы хранить твои эти 1.1. млн записей? значит проблемы нет вообще, запрос сразу передается клиенту без промежуточного хранения

Как ты предполагаешь СРАЗУ передать 1 млн записей?

Усилием мысли?

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

я не говорил СРАЗУ, данные постепенно передаются клиенту, а он их отображает после полного их получения

в ORACLE не так, там действительно на курсор много завязано

Результаты передаются клиенту по мере формирования на стороне сервера. Сервер вычисляет получающиеся записи, кладёт их в сетевой буфер отправки, и по его заполнению он отправляется клиенту . Клиент его получает, подтверждает чтение и помещает в свой буфер. После этого сервер может очистить выходной буфер и формировать набор далее. И так происходит в цикле пока не закончится весь набор данных.

я не говорил СРАЗУ, данные постепенно передаются клиенту, а он их отображает после полного их получения

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

в ORACLE не так, там действительно на курсор много завязано

Это не зависит от СУБД, все субд примерно так делают.

Потому что по-другому это не сделать.

Как консолька PG называется? Я не перепутал? psql ? Я уже забыл...

Psql

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

серьезно?

зачем только пагинацию придумали, непонятно

Результаты передаются клиенту по мере формирования на стороне сервера. Сервер вычисляет получающиеся записи, кладёт их в сетевой буфер отправки, и по его заполнению он отправляется клиенту . Клиент его получает, подтверждает чтение и помещает в свой буфер. После этого сервер может очистить выходной буфер и формировать набор далее. И так происходит в цикле пока не закончится весь набор данных.

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

может тогда имеет смысл сразу и записать на диск результат?

@ilyazver я не уверен что это из-за in медленно так. попробуй исключить из select все функции например и посмотреть что получится. хотя вижу что центроид уже предвычислен (а значит предварительн потрачен еще часик ? )

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

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

все так говорят ))

@ilyazver а еще меня смущает поле tags. это hstore?

не связано ли с ним замедление

В питоновском psycopg2 есть поддержка server-side курсоров, как раз для случаев, когда надо последовательно обрабатывать записи по мере прихода от бд из больших таблиц. cur = conn.cursor('some_uniq_name') cur.execute("SELECT * from some_big_table") for row in cur: break отрабатывает моментально и можно не дофетчивать до самого конца, если все что надо уже вытащили. Если же юзать обычный неименованный курсор, то будет долго висеть на execute

http://www.psycopg.org/psycopg/docs/usage.html#server-side-cursors

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

так какой вопрос-то?

так какой вопрос-то?

хочу создать бд и в ней таблицу, в которую можно вносить символы русской кириллицы. psql в терминале просто не дает вводить русские символы. в locale -a добавил русскую. CREATE DATABASE flowers ENCODING 'UTF-8' LC_COLLATE'ru_RU.UTF-8' LC_CTYPE'ru_RU.UTF-8'; ERROR: invalid locale name: "ru_RU.UTF-8" был бы очень признателен, если бы подсказали в какую сторону смотреть по всякому пробовал, ru_RU, ru_RU.UTF-8, ru_RU.UTF8

а кластер рестартовали после добавления локали в систему?

Command 'pg_lsclusters' not found, but can be installed with ..., это получается нужно PATH настроить?

какой дистрибутив?

xubuntu 18.04

service postgresql restart

service postgresql restart

спасибо добрый человек :)

Всем привет! WBCS и CryptoBazar Fund проводят хакатон 19 мая в Москве. Кому нужна ссылка, пишите в лс)

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

Сказочник...

В питоновском psycopg2 есть поддержка server-side курсоров, как раз для случаев, когда надо последовательно обрабатывать записи по мере прихода от бд из больших таблиц. cur = conn.cursor('some_uniq_name') cur.execute("SELECT * from some_big_table") for row in cur: break отрабатывает моментально и можно не дофетчивать до самого конца, если все что надо уже вытащили. Если же юзать обычный неименованный курсор, то будет долго висеть на execute

Да без разницы. Это те же яйца, только вид сбоку.

Сказочник...

в каком месте?

В душе наверное...

а по существу есть что сказать?

А вы про какие курсоры-то спорите? ;)

про эти:

Результаты передаются клиенту по мере формирования на стороне сервера. Сервер вычисляет получающиеся записи, кладёт их в сетевой буфер отправки, и по его заполнению он отправляется клиенту . Клиент его получает, подтверждает чтение и помещает в свой буфер. После этого сервер может очистить выходной буфер и формировать набор далее. И так происходит в цикле пока не закончится весь набор данных.

у Oracle кеш запросов есть

https://docs.oracle.com/database/121/TGDBA/tune_result_cache.htm

Postgresql  в этом плане в догоняющих, но у меня нет сомнений, что они к этому придут, так как у Oracle тоже он в свое время отсутствовал.

Пока что кеш у Postgresql используется в отдельных случаях, напримепр, в PL/pgSQL

Note: The current implementation of RETURN NEXT and RETURN QUERY stores the entire result set before returning from the function, as discussed above. That means that if a PL/pgSQL function produces a very large result set, performance might be poor: data will be written to disk to avoid memory exhaustion, but the function itself will not return until the entire result set has been generated. A future version of PL/pgSQL might allow users to define set-returning functions that do not have this limitation. Currently, the point at which data begins being written to disk is controlled by the work_mem configuration variable. Administrators who have sufficient memory to store larger result sets in memory should consider increasing this parameter.

https://www.postgresql.org/docs/9.5/static/plpgsql-control-structures.html

Результаты передаются клиенту по мере формирования на стороне сервера. Сервер вычисляет получающиеся записи, кладёт их в сетевой буфер отправки, и по его заполнению он отправляется клиенту . Клиент его получает, подтверждает чтение и помещает в свой буфер. После этого сервер может очистить выходной буфер и формировать набор далее. И так происходит в цикле пока не закончится весь набор данных.

А что тут не так-то? Если план/опции курсора позволяют, это именно так и работает, разве нет?

не всегда так работает

не всегда так работает

Да, есть вариант, когда всё сохраняется в памяти / временных файлах, а потом передаётся (по мере FETCH). Т.е. я не понимаю, кто что неправильно утверждал-то? ;)

Я кажется понимаю в чём проблема. cursor.execute() НЕ ВЫПОЛНЯЕТ запрос до конца. Он только НАЧИНАЕТ ВЫПОЛНЯТЬ запрос и формирует первую порцию данных. Остальные данные ВЫЧИСЛЯЮТСЯ по мере продвижения по курсору вперёд. В общем, твои представления о том, как мерить время запроса, немного неверны. Надо открыть курсор, и профетчить все данные

Я кажется понимаю в чём проблема. cursor.execute() НЕ ВЫПОЛНЯЕТ запрос до конца. Он только НАЧИНАЕТ ВЫПОЛНЯТЬ запрос и формирует первую порцию данных. Остальные данные ВЫЧИСЛЯЮТСЯ по мере продвижения по курсору вперёд. В общем, твои представления о том, как мерить время запроса, немного неверны. Надо открыть курсор, и профетчить все данные

И это _может быть_ правильно, опять-таки (если план и опции курсора позволяют), и что тут не так?

Я имел в виду, если тут действительно используются серверные курсоры, а не что-то "своё", что просто называется "курсором" в этом API.

Postgresql  в этом плане в догоняющих, но у меня нет сомнений, что они к этому придут, так как у Oracle тоже он в свое время отсутствовал.

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

Приглашаю завтра экспертов принять участие в круглом столе по БД на DC'18 https://www.devconf.ru/ru/offers/offer/385

А вы про какие курсоры-то спорите? ;)

Да тут в принципе не о чем спорить. Достаточно вчитаться в исходный вопрос автора, чтобы понять, что первый ответ (не считая флуда) от @MasterZiv не выдерживает никакой критики. Но если он не работает с постгрей из питона достаточно часто, то, в принципе, можно сделать на это скидку. Если бы cursor.execute() действительно возвращал управление после того как подгрузил только часть данных, то в принципе не возникло бы ситуации, когда execute и fetch занимает каждый примерно одно и то же время - час. И автор вопроса даже скинул пример кода - достаточно задать вот в этой строке https://github.com/Zverik/omim/blob/75264b67534e739c4219e9055b250f8f9f8742a9/tools/geocoder_pg/places_feed.py#L10 какое-нибудь уникальное имя для курсора, и вот тогда данные будут отдаваться по мере их прихода, а не копиться в огромного размера буфере на клиенте.

Да тут в принципе не о чем спорить. Достаточно вчитаться в исходный вопрос автора, чтобы понять, что первый ответ (не считая флуда) от @MasterZiv не выдерживает никакой критики. Но если он не работает с постгрей из питона достаточно часто, то, в принципе, можно сделать на это скидку. Если бы cursor.execute() действительно возвращал управление после того как подгрузил только часть данных, то в принципе не возникло бы ситуации, когда execute и fetch занимает каждый примерно одно и то же время - час. И автор вопроса даже скинул пример кода - достаточно задать вот в этой строке https://github.com/Zverik/omim/blob/75264b67534e739c4219e9055b250f8f9f8742a9/tools/geocoder_pg/places_feed.py#L10 какое-нибудь уникальное имя для курсора, и вот тогда данные будут отдаваться по мере их прихода, а не копиться в огромного размера буфере на клиенте.

А я тоже с psycopg2 не работал. Но если cursor в ней —- не настоящий серверный курсор (я бы так подумал, видимо, и @MasterZiv тоже), а что-то другое, что просто "обзывается" курсором, то тогда это совсем другое дело (и многие последующие рассуждения вообще к делу не относятся). ;)