> http://www.slideshare.net/ бан за пиар параши

@komar http://dump.bitcheese.net/files/uvyfeji/modernsqlinpostgresql-150130134147-conversion-gate01.pdf

@komar так тоже пойдёт, только кнопочек и стрелочек меньше, и ничего не понятно, куда нажимать.

> SQL has gone out of fashion lately—partly due to the NoSQL movement, but mostly because SQL is often still used like 20 years ago. > а давайте делать джойны вложенными селектами

Бля, смотрю на десятую страницу и нихуя не понимаю. Кто-то analyze не нажал, что ли?

@komar а вот там непонятно. Ставлю на то, что оптимизатор не умеет в nested loops. // кладу на самом деле

@gds Вот у меня он все умеет, а у них не умеет. Ладно, потом не будет лень — проверю, сейчас сплю уже на ходу.

> подзапросы хуйня ипаная ибо хз читать тяжело, давайте использовать with Ну это вообще пушка. WITH не оптимизируется вообще никак (и эту особенность я даже сумел использовать для грязных оптимизаций, лол). Чтобы было читаемо — надо CREATE TEMPORARY VIEW.

Ой, объясняют, как работает WITH RECURSIVE. Наконец-то я понял.

На странице 100 зачем-то изобрели велосипедный LIMIT, причем изобрели отвратительно. Если не выебываться с OVER(ORDER BY ...), а сделать ORDER BY подзапросом, то все соптимизируется.

@komar надеюсь, постгресик научится оптимизировать with. Иначе какой в этом смысл. Только для "сделай мне временную таблицу в пределах запроса"? temporary view, однако, тоже неплохо было бы.

@gds Ну это смотря чего мы хотим от этого with. Temporary view — это медленно и пиздец, я считаю. With в качестве алиаса для подзапроса выглядел бы гораздо лучше. Однако сейчас можно использовать with для того, чтобы зафорсить выборку строк. Иногда бывает полезно, я гарантирую это. В документации явно прописано, что with никак не оптимизируется, так что можно считать это фитчей, а не багом. Вот насколько мы ее хотим — это уже другой разговор.

@komar вот там я вообще не понял, что они хотели рассказать. select * from data order by x limit 10, и дальше чпокай эти данные как хочешь.

@gds Ну погодь. Мы в восемьсот лохматом году, лимит еще не изобрели.

@komar Бля, наврал, нихрена оно не оптимизирует. Странно, я с какого-то случая запомнил, что оно умеет отсекать по row_number()

TIL delete returning

TIL FILTER // such wow

TIL without overlaps // whoa

@anonymous да вообще обосраться

@kb на клиенте обрабатывал, небось?

@gds В смысле что куда удалял? Да, вообще sql выкинул (вместе с мэп-редьюсами и прочим хламом), все в памяти считаю.

@kb везуха. У меня часто не получается всё в память впихнуть.

@gds Да, у меня тут другая специфика, видимо. Тут SQL вообще не очень вариант изначально (5-этажные запросы по нескольку часов работали), не знаю кто додумался его впилить.

@kb а расскажи, что за задача такая, что sql никак? Мне это интересно потому, что считаю, что sql применим в большинстве задач, и хочется знать, где точно не стоит его применять, чтобы онус был цел.

@gds Ну как єто "никак". Был себе как много лет, просто превратился в многочасовые да еще и трехэтажные запросы при простоте задачи. Задача проста. Есть тонны событий, нужно считать их всякие там суммы и т.п. (например, события о просмотре страничек, нужно посчитать для каждого клиента за каждый час сумму просмотров и т.п.). Было так: сначала какие-то мап-редюсы через riak, потом выгруз в SQL и потом какие-то гигантские запросы. Вот пример одного из них (этот по дню суммирует, кажется, уже лень было вникать заново, выдрал рандомный кусок): https://gist.github.com/k-bx/8dfc7b78bd7eefabe059 Все это говно заменилось уютным пробегом всех событий в памяти, при этом описанием счетчиков в виде Fold'ов из библиотеки foldl: https://gist.github.com/k-bx/b6b4659875de7e11fe4d Я пьян, потому скорее всего сумбурно все описал, да и описывать в подробностях довольно долго, а может тебе что-то другое интересно. Если по поводу SQL -- я тут имел в виду что в принципе получается он узким местом при большом кол-ве данных, и либо его масштабировать (что реально, но геморно ведь), либо бежать от него (что для моих простых счетчиков всяких там довольно несложно).

@kb ты описал всё доступно и понятно. Мне было интересно именно это.

@gds надеюсь ты оценил трюк по первой ссылке с generatedNumbersAiBiCi

@kb ага. Изврат. В орацле я делал табличку с числами от 0 до 999, index-organized, а в постгресике взял бы generate_series или типа того.

@komar ты тупой блять

@anonymous а хули ты думал