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

не важно, есть ли else или нет) В офф примере с доки есть else, но там тоже самое происходит

без указания символов, на которых ошибка?

скиньте, что за пример

а в mysql нынче такие же кавычки?

другие тоже пробовал

а в каких кавычках текст этой хранимой процедуры?

https://dev.mysql.com/doc/refman/8.0/en/if.html

Это функция)

Точно так же ругается на первый END IF;

ну ты ж не в запрос этот иф пишешь?

Да, все верно. Я кинул ссылку на пример с документации

там точно такая же ошибка

может кто у себя на базе попробовать создать такую процедуру?

у нас постгрес

хочешь перейти на постгрес? :)

У меня на всех проектах постгрес, но тут ТЗ от заказчка указывает, что надо использовать MySQL

Собственно проект изначально был написан на posgtres и теперь он мигрирует в MySQL

причины?

не вдавался в подробности. Просто есть четкое тз написать миграционные скрипты с PostgreSQL 9.5 на MySQL 5.6

Сейчас занят тем, что переписываю функции и вот столкнулся с проблемой вот этой, что не работают условия)

https://en.wikibooks.org/wiki/Converting_MySQL_to_PostgreSQL об отличиях кавычек и тд там ниже таблица

Да, но вот только с кавычками то все ок. Пробовал и другие, но результат тот же

К тому же это просто строка возврата из функции

всем привет! подскажите куда копнуть. делается выборка с 4 последовательными join'ами. нужно лимитировать второй и третий джойн. т.е. чтобы на каждую запись первой выборки джойнилось не больше 5 записей из второй, к ним не больше 5 записей на каждую из третьей и т.д.

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

Задать общий лимит для select?

тогда отлимитируется итоговый результат

а мне нужно джойнить не больше N строк на каждую строку другой выборки

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

Как вариант - сделать подзапросы, если приемлемо.

выбираем 5 строк. к ним джойним 50 с общим лимитом 10. в результате получим только одну первоначальную строку из 5 с 10 приджойненными

Как вариант - сделать подзапросы, если приемлемо.

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

Как вариант - сделать подзапросы, если приемлемо.

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

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

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

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

я предполагаю использование lateral c лимитом во внутреннем подзапросе https://www.postgresql.org/docs/current/static/queries-table-expressions.html#QUERIES-LATERAL

спасибо, почитаю. если у кого есть еще мысли буду рад услышать

спасибо, почитаю. если у кого есть еще мысли буду рад услышать

То же самое, наверное, можно сделать с nested query + ROW_NUMBER(). Но вариант с LATERAL, скорее всего, проще.

Помогите решить вопрос по sql)

вторых изменить так, чтобы s4 возвращало не минимальную закупочную цену(выделено красным), а закупочную цену последнего прихода данного товара. Дата прихода в поле DayFirst, надо делать через join дополнительной таблицы, в которой находим эти цены для каждого DrugsID (кода товара)

вторых изменить так, чтобы s4 возвращало не минимальную закупочную цену(выделено красным), а закупочную цену последнего прихода данного товара. Дата прихода в поле DayFirst, надо делать через join дополнительной таблицы, в которой находим эти цены для каждого DrugsID (кода товара)

А вы уверены, что это именно запрос PostgreSQL?

не особо уверен подсказали обратиться сюда)

@sqlru

Привет всем Подскажите, кто на 10.3 юзал нативное партицирование, не сталкивались ли с Out of shared memory?

У меня эти партиция плодятся и заполняются адскими темпами, типа свечки с разных бирж, каждый график в своей партиции. На серваке памяти до жопы, но постгрес о ней не знает. Больше 3-4 гиг не видел чтоб было занято. Может, подскажете, что в conf писать?

У меня эти партиция плодятся и заполняются адскими темпами, типа свечки с разных бирж, каждый график в своей партиции. На серваке памяти до жопы, но постгрес о ней не знает. Больше 3-4 гиг не видел чтоб было занято. Может, подскажете, что в conf писать?

А зачем вам вообще партиции? И какими темпами они "плодятся и заполняются", конкретнее?

Примерно 25к

Они для того, чтобы в отдельных таблицах все таймсерии были. До этого данных было меньше, все падало в одну таблицу с двумя индексами и она стала неподъёмной. Решили порезать ее на части, сначала все пошло хорошо, но как только начали заполнять данными, начало падать.

Примерно 25к

Это ответ на какой из вопросов? И 25k чего?

> Они для того, чтобы в отдельных таблицах все таймсерии были. С какой целью?

Это про количество партиций

Чтобы была не одна гигантская таблица, а много маленьких

С планом самые тяжелые куда-то ещё вынести.

Когда старая таблица за сотню гигов перевалила, запросы стали неприемлемо долгими, от полминуты до полторы. Поэтому грешили на неё

Это про количество партиций

Ну так это и не должно было работать. :( Вы предупреждение в конце https://www.postgresql.org/docs/current/static/ddl-partitioning.html читали? Вот это, конкретно: Partitioning using these techniques will work well with up to perhaps a hundred partitions; don't try to use many thousands of partitions.

Щит. Эту строчку пропустил, конечно же.

Когда старая таблица за сотню гигов перевалила, запросы стали неприемлемо долгими, от полминуты до полторы. Поэтому грешили на неё

А индексировать пробовали? Партиционирование —- это вовсе не magic fairy dust, и им не так уж просто даже немного улучшить производительность (по сравнению с индексированием), а вот провалить её —- запросто (как вы сами и убедились, к сожалению). :(

Может, надо добавить памяти где-то в конфиге? Или эта история вообще не вписывается в постгрес и надо что-то иное?

Да, так и вышло. На паре сотен работало идеально, даже локально.

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

Может, надо добавить памяти где-то в конфиге? Или эта история вообще не вписывается в постгрес и надо что-то иное?

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

Может, надо добавить памяти где-то в конфиге? Или эта история вообще не вписывается в постгрес и надо что-то иное?

Вам надо решать проблемы нормальными средствами, а не надеяться на волшебную пыль, IMHO. ;)

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

Ну так и индексируйте соответственно...

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

Ну так и индексируйте соответственно...

То есть разумнее сделать условные индексы, но таблицу сделать монолитной?

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

Очевидно, он не подходит для ваших запросов. Какие они у вас (можете примерно показать)?

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

64 гиг памяти, 8 ядер

То есть разумнее сделать условные индексы, но таблицу сделать монолитной?

Так вы пробовали делать обычные, подходящие под запросы индексы?

Очевидно, он не подходит для ваших запросов. Какие они у вас (можете примерно показать)?

Для каждой таблицы один свой собственный

Для каждой таблицы один свой собственный

Для той монолитной таблицы, я имел в виду.

Для той монолитной таблицы, я имел в виду.

Для той один индекс был.

Для той один индекс был.

Ясно. Так запросы примерно какие?

Иными словами мне нужно сделать единую таблицу и индивидуальные индексы? Там запросы в основном содержат биржу, пару, время начала и конца периода. По каждому индексы были, по ночам даже вакуум кроном запускался.

Но это мне уже как легаси досталось. А сейчас новые источники данных добавляются, и в ту же таблицу писать не вариант было.

Поэтому обновили с 9.6 до 10.3 и сделали партиции

Иными словами мне нужно сделать единую таблицу и индивидуальные индексы? Там запросы в основном содержат биржу, пару, время начала и конца периода. По каждому индексы были, по ночам даже вакуум кроном запускался.

Вам с этого надо было начинать, да. Что такое "содержат"? Что-то вроде "SELECT что? FROM table WHERE биржа = 'x' AND пара = 'y' AND timestamp BETWEEN 'a' AND 'b'? [GROUP BY ?] [ORDER BY ?]"?

Именно так. С order, но без группировок. Хотя может и был где-то запрос с группировками.

Поэтому обновили с 9.6 до 10.3 и сделали партиции

Вы бы хоть сначала спросили где-нибудь (так, на будущее, есть же и mailing lists, и #postgresql (IRC), и SQL.RU, и этот канал). ;)

Именно так. С order, но без группировок. Хотя может и был где-то запрос с группировками.

Ну так и был(и) у вас соответствующие составные индексы, т.е. CREATE INDEX ON table(биржа, пара, timestamp), как минимум?

Момент

вот такие индексы были ["index_pair_histories_on_created_at", "index_pair_histories_on_data_point_kind", "index_pair_histories_on_pair_id", "index_pair_histories_on_pair_id_and_timestamp_at", "index_pair_histories_on_source", "index_pair_histories_on_timestamp_at"]

сейчас такие ["okex_spot_rcn_btc_20mins", "okex_spot_light_eth_20mins", "okex_spot_fair_btc_20mins"]

по одному на каждую партицию

вот такие индексы были ["index_pair_histories_on_created_at", "index_pair_histories_on_data_point_kind", "index_pair_histories_on_pair_id", "index_pair_histories_on_pair_id_and_timestamp_at", "index_pair_histories_on_source", "index_pair_histories_on_timestamp_at"]

Ну это же просто названия... ну ладно, если они были созданы без явного указания имени, то единственный составной здесь index_pair_histories_on_pair_id_and_timestamp_at (наверное: (pair_id, timestamp_at))... и где в нём биржа? И некоторые из остальных, скорее всего, не подойдут для большинства запросов. :(