Вы бы вставляли в виде текста (всё, о чём Вас просили) на какой-нибудь paste site, а сюда ссылку.

https://pastebin.com/p0K7W9Q9 тут тот самый первый селект

Это на самом деле не так. Есть тысяча и одно объяснение что вам так делать не надо.

Спасибо, я пожалуй пойду работать

https://pastebin.com/p0K7W9Q9 тут тот самый первый селект

_Всё_, о чём Вас просили. Понимаете, без всего ранее перечисленного это обычно просто потеря времени. Для всех.

наконец-то чтото нормальное

Не ложится на бит объявление - спам значит

Оо, спс. Сейчас попробую

ну чо

ну чо

создается индекс

долговато

ну ладно

та же херня(

первый секунд на 20 второй на 0.9

план покаж

сек

сейчас попробую залить план на тот сайтик

не заливай, индекс не юзается новый

ок. дропну тогда его

а запрос из https://pastebin.com/p0K7W9Q9 тоже его не берет?

угу. тоже

вот тут хороший кейс поставить https://github.com/dalibo/hypopg и поиграться

угу. тоже

Продолжаете терять время. ;(

Пробую оптимизировать запрос

create index concurrently on estate_properties(building_area,latest_sale_recording_date);

а почему вы не включили сам ключ джойна в индекс - property_place_id?

ну это не обязательное условие для работы индекса

Кстате, какой кост запроса считается слишком большим ?

чую холивор на ночь

Кстате, какой кост запроса считается слишком большим ?

Тот, который не влезает в double. ;)

Тот, который не влезает в double. ;)

Та ладно, я костов больше 3 млн не видел

Та ладно, я костов больше 3 млн не видел

Зависит от сложности плана, настроек и размера базы, очевидно. А Вам зачем?

Та веб, в основном, ничего сложного в общем, да и база маленькая, где-то 4-5 гб всего-то

Та веб, в основном, ничего сложного в общем, да и база маленькая, где-то 4-5 гб всего-то

И что? (По-моему, это не ответ на мой вопрос...)

лайфхак, когда кост становится слишком большим, ставь все косты в десять раз меньше!

Та ладно, я костов больше 3 млн не видел

Я видел за триллионы при запросе работающим несколько минут

Кто с py-postgresql работает? Может ткнуть в доку, где объяснено что возвращают запросы?

Ну, типа, SELECT - понятно. А вот INSERT возвращает INSERT, DELETE - DELETE. Это где-то описано? И как ошибки обрабатывать?

Неужели через try ... catch?

Это, наверное, к питонистам

Ну, типа, SELECT - понятно. А вот INSERT возвращает INSERT, DELETE - DELETE. Это где-то описано? И как ошибки обрабатывать?

(я сам psycopg2 использую, но) может, это? »> print(r[0]) INSERT »> print(r[1]) 1 The execution of DML will return a tuple. This tuple contains the completed command name and the associated row count. https://pythonhosted.org/py-postgresql/driver.html#inserting-and-dml

Верно, спасибо!

А что, psycopg2 лучше? Удобнее?

Дак я py-postgresql не пробовал, сравнить не могу ) А ошибки наверняка через try/except, и это нормально

Говорят, что py-postgresql медленнее, но я в этом сомневаюсь. Сам всегда использовал psycopg2, но прочитал этот пост (особенно, комментарии) и задумался: https://m.habrahabr.ru/post/120128/comments/

@pasha_golub @Komzpa и что б два раза не вставать ))

Банхаммер в студию)))))

Банхаммер применен

Пробую оптимизировать запрос

А pg_prewarm Вы пробовали?

Всем привет! С разрешения админа группы публикую и предлагаю рассмотреть вакансию Разработчик БД PostgreSQL https://www.comagic.ru/about/career/12307/ . Работа в Москве, в офисе, в шаговой доступности от м. Нахимоский проспект, full time, вилка по з/п: 160К - 190К net. Ещё немного о нас, доклад нашего CTO на pgconf 2017 https://pgconf.ru/2017/93999 Буду рада резюме:) Хорошего дня! #работа#fulltime#postgreSQL#москва

А pg_prewarm Вы пробовали?

Нет пока.

Буду гуглить, что это

это стандартный extension, включённый в дистрибутив, для прогрева кэша.

это стандартный extension, включённый в дистрибутив, для прогрева кэша.

Он многопоточно греет ?

Он многопоточно греет ?

нет в один поток

хотя на уровне приложения можно распараллелить вызов pg_prewarm

нет в один поток

Тогда руками лучше либо пускать индексканы во много потоков, чтобы в буфера загнать или dd параллельно чтобы в ос кеш // например

хотя на уровне приложения можно распараллелить вызов pg_prewarm

Ммм, ок

Ммм, ок

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

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

Ок, я понял

Тогда руками лучше либо пускать индексканы во много потоков, чтобы в буфера загнать или dd параллельно чтобы в ос кеш // например

ос кэш можно асинхронно через madvise прогревать - опция prefetch

А в какой системе (ОС)? А может, они просто idle?

А tcpdump что показывает? С точки зрения системы keep-alive есть?

2 попытки ил 2 пакета?

Т.е. это информация из sysctl?

Выглядит логично.

А где видны коннекты в статусе sleep?

net.ipv4.tcp_tw_reuse = 1

А со стороны сервера netstat или ss что говорит?

nginx это использует для овердофига короткоживущих соединений