Кстати, я от @bobrovskiy_roman. Знаете такого?

ну в 3м же просто join сделать и where

Theta Join = this is the general join everybody uses because it allows you to specify the condition (the ON clause in SQL).

ну в 3м же просто join сделать и where

Можно чуть подробнее? Я не понял...

По name НЕ НАДО индекс, если по ней только сортировка.

Там пагинация еще нужна. 150к записей

2. Дано отношения r1 and r2. Обьяснить возможность/невозможность вычисления пересечения этих отношений r1 intersect r2. Найдите его, если это возможно. 3. Даны отношения r1 and r2. Обьяснить возможность/невозможность вычисления ∅-обьединением отношения r1 по атрибуту field 1 с отношением r2 по атрибуту field 3 этих отношений A times B where field 1 = field 4. Найдите его если это возможно.

Какой мудила эти задания составлял? Пересечение ПО КАКИМ ПОЛЯМ? Так конечно их можно пересечь, по Field2 == Field5, но из одного домена эти поля или нет — не ясно. По второму вопросу я не зняю этого термина , Тета-объединение.

Там пагинация еще нужна. 150к записей

Пагинацию сразу же нафиг...

Какой мудила эти задания составлял? Пересечение ПО КАКИМ ПОЛЯМ? Так конечно их можно пересечь, по Field2 == Field5, но из одного домена эти поля или нет — не ясно. По второму вопросу я не зняю этого термина , Тета-объединение.

Второе я понял. Найти совпадающие строки (их нет, ибо тип тоже важен)

Там пагинация еще нужна. 150к записей

Это в таблице 150 тыщ, или выборка результирующая?

Второе я понял. Найти совпадающие строки (их нет, ибо тип тоже важен)

Ну это специфические термины твоего лектора, я их не знаю.

Ну это специфические термины твоего лектора, я их не знаю.

Intersect в SQL нет?

Это в таблице 150 тыщ, или выборка результирующая?

В таблице. Что значит пагинация нафиг?

Intersect в SQL нет?

Нет. Почти нет.

В таблице. Что значит пагинация нафиг?

Выбрасывай сразу же. Хотя, дело твоё, личное. Можешь потрахаца.

Что значит выбрасывай когда ради неё все и делается. Она не через offset разумеется, а через < > на name

Intersect в SQL нет?

Я про Тета-объединение говорил, а не про это

Что значит выбрасывай когда ради неё все и делается. Она не через offset разумеется, а через < > на name

Ладно, давай вернёмся к проблеме.

Что значит выбрасывай когда ради неё все и делается. Она не через offset разумеется, а через < > на name

Как это постраничный вывод через <> name ? Врочем, вопрос риторический, если ты знаешь, то и хорошо.

Известно как - вторая страница начинается с последнего name на первой

В таблице. Что значит пагинация нафиг?

ЕСЛИ у тебя в таблице только 150 тыщ записей, то это не очень много. Ты можешь насоздавать индексы как было указано выше, и на этом успокоиться. Никакой columnstore тут естественно не нужен. Максимум что придётся сделать, это запинить таблицу в кэш, если это возможно.

Известно как - вторая страница начинается с последнего name на первой

Классные у тебя таблицы... Аж завидно.

150 тыщ, но там на самом деле ещё пачка других колонок. Индексы по нескольким числовым колонкам не вижу смысла, поскольку их набор не известен. Вопрос насколько хорошо будет работать partial индекс

Классные у тебя таблицы... Аж завидно.

Что тут необычного? Я думал так в детском саду учат пагинацию делать

150 тыщ записей и последовательным поиском можно достаточно быстро перебрать. Особенно если задействовать параллелизм.

Что тут необычного? Я думал так в детском саду учат пагинацию делать

Да я б убил того идиота, который её придумал...

150 тыщ записей и последовательным поиском можно достаточно быстро перебрать. Особенно если задействовать параллелизм.

Ну там какие-то условия поиска можно оптимизировать.... А остальное — да, тупо перебором.

Нет, последовательно слишком медленно

Плюс джойны

Что делает слово times в SQL?

Нет, последовательно слишком медленно

Медленно — это как для тебя?

Это больше полсекунды

Это больше полсекунды

А можете показать \d таблицы, пример запроса + EXPLAIN (ANALYZE, BUFFERS)?

А что говорит explain analyze на план выполнения запроса?

Прямо сейчас нет

Я писал что говорит explain конкретно для этих колонок, по ним всё укладывается, вопрос был в том можно ли там оптимизировать жирные индексы

Я писал что говорит explain конкретно для этих колонок, по ним всё укладывается, вопрос был в том можно ли там оптимизировать жирные индексы

Ну, тебя всё равно надо брать каждый тормозящий запрос и под него делать индекс. Потом другой — и под него индекс и так далее. что такое при этом "жирные" индексы — не ясно. Таблица маленькая, все индексы тоже.

Я писал что говорит explain конкретно для этих колонок, по ним всё укладывается, вопрос был в том можно ли там оптимизировать жирные индексы

МОжешь дать запросец (и опред. таблицы ), я тебе напишу индекс, а дальше поймёшь сам уже

Это я и сам могу. Меня интересовали хитрые типы индексов и подводные камни partial индекса только по менее селективной части ключа

Это я и сам могу. Меня интересовали хитрые типы индексов и подводные камни partial индекса только по менее селективной части ключа

запрос покажи

Это я и сам могу. Меня интересовали хитрые типы индексов и подводные камни partial индекса только по менее селективной части ключа

ТАм нет каких-то хитростей, надо просто брать каждый запрос и делать под него иднекс. Менее селективный или более — не важно, у тебя ОДНО значение может быть НЕ селективным, зато ДВА ИЛИ ТРИ — очень селективным.

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

Так составные индексы надо делать...

а ктонидь уже пробовал крутить постгре на Intel Optane™ SSD ?

есть ли профит и резон?

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

вопрос в контексте статьи:

На сервере была установлена ОС Ubuntu 16.04 с ядром 4.13. Обратите внимание! Чтобы получить хорошую производительность NVMe-накопителей, требуется версия ядра не ниже 4.10. С более ранними версиями ядра результаты будут хуже: поддержка NVMe в них надлежащим образом не реализована. https://habrahabr.ru/company/selectel/blog/352622/

"Чтобы получить хорошую производительность NVMe-накопителей, требуется версия ядра не ниже 4.10. С более ранними версиями ядра результаты будут хуже: поддержка NVMe в них надлежащим образом не реализована." - вдруг для кого-то это будет откровением, чтобы не бодаться с тормозами на потенциально ракетном железе

"Чтобы получить хорошую производительность NVMe-накопителей, требуется версия ядра не ниже 4.10. С более ранними версиями ядра результаты будут хуже: поддержка NVMe в них надлежащим образом не реализована." - вдруг для кого-то это будет откровением, чтобы не бодаться с тормозами на потенциально ракетном железе

Что-то у них последовательная запись через БД в5 раз медленнее чем диск умеет.

тота и оно, что железо свежайшее и крайне не дешёвое - потому и присматриваться к нему нужно осмотрительно и взвешенно

всем привет) подскажите, пожалуйста, для чего нужен и где используется search_path базы ? search_path пользователя или функции понятно, а в каких кейсах search_path базы нужен не смог найти

всем привет) подскажите, пожалуйста, для чего нужен и где используется search_path базы ? search_path пользователя или функции понятно, а в каких кейсах search_path базы нужен не смог найти

что бы искать данные в нужных схемах

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

например у тебя есть схема main1_ main2 и тд

вот есть два альтера alter role test_role in database test_db set search_path = test_schema_2, test_schema_1; alter database test_db set search_path = test_schema_1, test_schema_2;

первый скажет, что под юзером, на которого намаплена роль test_role ищи сперва в схеме test_schema_2, затем по цепочке

а что сделает второй? что он зааффектит?

Правда никто не знает?:)

Смотря от какого пользователя выполняются команды. Если в конфликт войдут, то альтер роли в приоритете будет. Мону ошибаться. Посмотрите в доке.

В доке не нашёл никаких разъяснений

Не уверен, что они там есть вообще

Судя по экспериментам пользователю все равно на search_path бд в любом случае

Тем более у него всегда есть две дефолтные схемы, не совсем понял какой конфликт?

ERROR: S client not available

Конфликт чего с чем?

не поленился, глянул в доку вот https://www.postgresql.org/docs/current/static/sql-alterdatabase.html гляньте в Notes

есть запрос он выполняеться более 5тыс раз из за чего проседает бд можете подсказать как можно оптимизировать запрос или сделать решение которое ускорит вывод SELECT cdr.start_stamp as start_call, cdr.answer_stamp as takeoff, ivr_result.digits as press_key , ivr_result.time as press_key_time, cdr.end_stamp as hangup, cdr.billsec as call_duration, golang.uuid, cdr.hangup_cause, cdr.cc_record_filename, cdr.destination_number FROM golang LEFT JOIN result_obzvon ON golang.session_id = result_obzvon.session_id LEFT JOIN ivr_result ON golang.session_id=ivr_result.session_id LEFT JOIN cdr on golang.uuid = cdr.uuid WHERE golang.session_id = 'SWRZBwIsfh';

таблицы индексированы

не поленился, глянул в доку вот https://www.postgresql.org/docs/current/static/sql-alterdatabase.html гляньте в Notes

спасибо! неочевидно, что это к search_path относится

на тестах, правда, все наоборот опять же

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

вот полный скрипт, тыкните плиз, где я что-то упустил

create database test_db; \c tet_db create schema test_schema_1; create schema test_schema_2; create user test_user; alter user test_user with password 'test_user'; create user test_user2; alter user test_user2 with password 'test_user2'; create role test_role; alter user test_user set role test_role; alter role test_role in database test_db set search_path = test_schema_2, test_schema_1; alter database test_db set search_path = test_schema_1, test_schema_2; create table test_schema_1.test_table(data text); insert into test_schema_1.test_table values('test_table_1'); grant select on table test_schema_1.test_table to test_user; grant select on table test_schema_1.test_table to test_user2; create table test_schema_2.test_table(data text); insert into test_schema_2.test_table values('test_table_2'); grant select on table test_schema_2.test_table to test_user; grant select on table test_schema_2.test_table to test_user2; grant usage on schema test_schema_1 to test_user; grant usage on schema test_schema_1 to test_user2; grant usage on schema test_schema_2 to test_user; grant usage on schema test_schema_2 to test_user2; \q

при коннекте psql -h 0.0.0.0 -p 5432 -U test_user -d test_db -W вижу, что все наоборот

нашел ответ, посмотрев на обрезанный кусок скрина)

всем спасибо)

есть запрос он выполняеться более 5тыс раз из за чего проседает бд можете подсказать как можно оптимизировать запрос или сделать решение которое ускорит вывод SELECT cdr.start_stamp as start_call, cdr.answer_stamp as takeoff, ivr_result.digits as press_key , ivr_result.time as press_key_time, cdr.end_stamp as hangup, cdr.billsec as call_duration, golang.uuid, cdr.hangup_cause, cdr.cc_record_filename, cdr.destination_number FROM golang LEFT JOIN result_obzvon ON golang.session_id = result_obzvon.session_id LEFT JOIN ivr_result ON golang.session_id=ivr_result.session_id LEFT JOIN cdr on golang.uuid = cdr.uuid WHERE golang.session_id = 'SWRZBwIsfh';

Ээээ.... не выполнять 5000 раз? ;) Т.е. 5000 раз индентичный запрос, или что-то всё же меняется? Затем, нельзя ли эти 5000 переписать в один запрос?

golang.session_id как индексирован?

CREATE INDEX session_id_idx ON golang (session_id);

Смотрю index_scan там тяжеловат

Если попробовать HASH индекс?

Только прочитайте про него внимательно предварително

Подойдет ли вам

спасибо почитаю

CREATE INDEX session_id_idx ON golang (session_id);

Так что, ни запрос, ни "5000 раз" вы изменить не можете? Только индексы/настройки?

есть запрос он выполняеться более 5тыс раз из за чего проседает бд можете подсказать как можно оптимизировать запрос или сделать решение которое ускорит вывод SELECT cdr.start_stamp as start_call, cdr.answer_stamp as takeoff, ivr_result.digits as press_key , ivr_result.time as press_key_time, cdr.end_stamp as hangup, cdr.billsec as call_duration, golang.uuid, cdr.hangup_cause, cdr.cc_record_filename, cdr.destination_number FROM golang LEFT JOIN result_obzvon ON golang.session_id = result_obzvon.session_id LEFT JOIN ivr_result ON golang.session_id=ivr_result.session_id LEFT JOIN cdr on golang.uuid = cdr.uuid WHERE golang.session_id = 'SWRZBwIsfh';

В запросе связанные переменные используются? Или он прямо так? Либо нужно связанные переменные (при условии что будет server-side prepared statement), либо можно завернуть запрос в pl/pgsql -- там server prepared начнут использоваться

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

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

Да. Не обратил внимание на время планирования. По поводу prepared - там план может измениться - без конкретных значений в фильтрах.

Хотя тут вероятно session_id уникальный (для этого конкретного значения - rows 1) или близкий к тому

таблицы индексированы

Может выбирать данные пачками а не по 1 записи?

Ну тут же от задачи зависит.

В итоге перетпшил таблицу в оперативную память и переделал логику. Спасибо за советы.