Как нужно зарабывать деньги на OpenSource

Если будет много одинаковых запросов - не проще ли просто кэшировать результаты? Если не одинаковые, но похожие, то как определять степень похожести?

Если будет много одинаковых запросов - не проще ли просто кэшировать результаты?

вообще-то одинаковые запросы != одинаковые результаты, да и запросы бывают разные - на вставку, удаление, изменение etc.

У постгреса сто лет уже есть PREPARE ровно с той целью, чтобы не интерпретировать каждый раз одни и те же запросы, а тут, вишь, инновации.

У постгреса сто лет уже есть PREPARE ровно с той целью, чтобы не интерпретировать каждый раз одни и те же запросы

чтоб не парсить, а не интерпретировать

т.е. по-твоему, будет большой профит от того, что ты не возьмёшь подготовленный сценарий и в цикле прогонишь вызовы, а вызовешь их из скомпилированного кода? не, ты правда так думаешь? или я чего-то не догоняю?

Как нужно зарабывать деньги на OpenSource (комментарий)

в конце

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

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

пример - у тебя запрос ищет запись по условию, надо делать цикл и выполнять проверку, а теперь сравни скорость данного цикла и выполнения проверок в обоих случаях

Поэтому, как я считаю, сия мера - ближайший аналог PREPARE.

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

И ещё есть такой момент, что один и тот же запрос может обрабатываться разными сценариями в зависимости от собранной по базе статистики.

И ещё есть такой момент, что один и тот же запрос может обрабатываться разными сценариями в зависимости от собранной по базе статистики.

не проблема же - всегда можно сделать по другому

надо делать цикл

хотя конечно не все СУБД сделают это в интерпретаторе, неудачный пример

пример - у тебя запрос ищет запись по условию, надо делать цикл и выполнять проверку, а теперь сравни скорость данного цикла и выполнения проверок в обоих случаях

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

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

Опять, щито? PREPARE парсит запрос, составляетплан и сохраняет, если так можно выразиться, его в байт коде, что в следущий раз можно просто взять и по нему вызвать те самые low-level API и ничего больше не парсить. Какое, блин, и так на руках, ты о чём вообще?

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

Щито? Как это вообще относится?

читай доки по sqlite, там сделано именно так

Опять, щито? PREPARE парсит запрос, составляетплан и сохраняет, если так можно выразиться, его в байт коде, что в следущий раз можно просто взять и по нему вызвать те самые low-level API и ничего больше не парсить. Какое, блин, и так на руках, ты о чём вообще?

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

читай доки по sqlite, там сделано именно так

Так ты объясни по-человечески, что именно «так» то?

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

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

и даже больше - некоторые СУБД сами кешируют промежуточные данные, так что руками PREPARE вызывать не надо

Так ты объясни по-человечески, что именно «так» то?

проход по записям и проверки

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

даю намек - на это тоже тратится время

Проход по записям отрабатывается в цикле интерпретатора? Что, серьёзно? И что, на каждый ряд парсится заново запрос, или что?

На что «на это»? На то, чтобы раз в жизни сделать PREPARE? Даю намёк, на компиляцию потратится больше.

Проход по записям отрабатывается в цикле интерпретатора? Что, серьёзно?

да

И что, на каждый ряд парсится заново запрос, или что?

нет конечно, откуда у тебя такая мысль вообще взялась

На то, чтобы раз в жизни сделать PREPARE?

и на это тоже, только тебя куда-то не туда понесло

Даю намёк, на компиляцию потратится больше.

я скажу даже больше - компиляция работает только в паре с «PREPARE»

нет конечно, откуда у тебя такая мысль вообще взялась

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

1) запрос распарсили; 2) поняли чё надо делать; 3) в функции прошли по всем записям (если нет индекса), накопили ответ и вернули.

Как здесь компиляция поможет, кроме того, что уберёт первые фазы и сразу вызовет третью?

и на это тоже, только тебя куда-то не туда понесло

Эти потери точно такие же, как с компиляцией. Несёт меня повсюду, ибо я пытаюсь брутфорсом понять, о чём ты вообще говоришь.

я скажу даже больше - компиляция работает только в паре с «PREPARE»

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

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

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

Я сказал, что это «нововведение» - суть PREPARE из постгреса, ты сказал, что вообще не то, вот это и пытаюсь выяснить - где разница зарыта.

Я сказал, что это «нововведение» - суть PREPARE из постгреса, ты сказал, что вообще не то

да, т.к. компиляция идет после «PREPARE», это другой шаг, «PREPARE» - это то, что СУБД выполняет в любом случае, пользователь может лишь помочь не делать этого постоянно, вобщем у нас видимо спор просто из-за разной интерпретации задачи

выполняет в любом, но постгрес позволяет результаты PREPARE сохранить и в следущий раз уже не делать PREPARE, а сразу заняться его исполнением. Т.е. вся разница в том, что при компиляции цикл раскрыт, т.е. мала. Т.е. по сути PREPARE и делает компиляцию запроса, только не в нативный, а в байт-код.

но постгрес

да не только он, даже sqlite это умеет

Т.е. по сути PREPARE и делает компиляцию запроса, только не в нативный, а в байт-код.

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

хотя опять же - это про postgre, а sqlite - да, шмалит все в байт-код под свою VM

Не суть, кто умеет, с чем больше общаюсь, про то и пишу :)

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

Чем эти порождённые структуры принципиально отличаются от байт-кода

тем, что это данные, а не программа - т.е. разница именно принципиальная

И что там могут быть за данные? Не понятно, как и зачем они туда попали. Я не буду сильно спорить, ибо в код постгреса я не лазил, но ман говорит: «When an EXECUTE command is subsequently issued, the prepared statement need only be executed.» Что, как мне кажется, очень похоже на то, что я описывал.

И что там могут быть за данные?

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

Что, как мне кажется, очень похоже на то, что я описывал.

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

Ну на том и сойдёмся, профит в фиче сомнителен.