это не в конкретном языке, это в базе данных есть

это не в конкретном языке, это в базе данных есть

Даже так. Просто я помню что в php добавляли такой механизм

Кстате нормально ли использовать часто тип String (из sequelize) для маленьких строк до 30 символов?

А про это что скажете?

Кстате нормально ли использовать часто тип String (из sequelize) для маленьких строк до 30 символов?

А блет

это просто varchar

Отдельно шлется запрос, отдельно параметры к нему. В идеале БД парсит запрос, выполняет нужный анализ, может быть, даже компилирует его, а потом драйвер просто передает параметры. Понятное дело, что это дороже и не нужно, если надо просто один раз выполнить запрос, но я не знаю, существует ли такое в разных БД вообще - просто передать запрос и параметры без prepared.

Отдельно шлется запрос, отдельно параметры к нему. В идеале БД парсит запрос, выполняет нужный анализ, может быть, даже компилирует его, а потом драйвер просто передает параметры. Понятное дело, что это дороже и не нужно, если надо просто один раз выполнить запрос, но я не знаю, существует ли такое в разных БД вообще - просто передать запрос и параметры без prepared.

в мускуле точно нет

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

Да я хозе обычно если какой то трабл со строками то экранирую

извините за тупой вопрос, но как экранировать кавычку?))

извините за тупой вопрос, но как экранировать кавычку?))

\'

а, то есть я правильно делал

просто не работает))

а, то есть я правильно делал

правильно использовать prepared statements ???

правильно использовать prepared statements ???

да все-все))

Отдельно шлется запрос, отдельно параметры к нему. В идеале БД парсит запрос, выполняет нужный анализ, может быть, даже компилирует его, а потом драйвер просто передает параметры. Понятное дело, что это дороже и не нужно, если надо просто один раз выполнить запрос, но я не знаю, существует ли такое в разных БД вообще - просто передать запрос и параметры без prepared.

> существует ли такое в разных БД вообще - просто передать запрос и параметры без prepared. Например, в PostgreSQL — условно, да (хотя это всё равно несколько сообщений в протоколе). Но дело тут на самом деле в "глубине" обработки запроса, я думаю.

а, то есть я правильно делал

Нет, неправильно. Правильно использовать parameterized statements.

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

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

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

ок спасибо

> существует ли такое в разных БД вообще - просто передать запрос и параметры без prepared. Например, в PostgreSQL — условно, да (хотя это всё равно несколько сообщений в протоколе). Но дело тут на самом деле в "глубине" обработки запроса, я думаю.

Как это - да? Передать запрос так, чтобы он не был разобран и отдельно передать параметры?

Как это - да? Передать запрос так, чтобы он не был разобран и отдельно передать параметры?

Эээ... а какая разница, когда он будет "разобран"? Всё равно это случится хотя бы один раз.

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

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

А разница-то какая? Это же шило на мыло, нет?

Вопрос перечитайте плз)

Вопрос перечитайте плз)

Ответ перечитайте плз)

Разницы никакой, но в постгресе такого нет

Разницы с точки зрения результата никакой

Так правильнее

Разницы никакой, но в постгресе такого нет

Вообще, разница могла бы быть (если кому-то хочется экономить на roundtrips). Но да, в PostgreSQL этим не стали заморачиваться. :)

Хотя не, не прав. Разница ест

В случае, если запрос парсится с известными параметрами, при планировании могут быть учтены сами значения этих параметров. Так что разница в подходах есть

В случае, если запрос парсится с известными параметрами, при планировании могут быть учтены сами значения этих параметров. Так что разница в подходах есть

А вот PostgreSQL учитывает их всё равно. :) Вопрос, опять-таки, в "глубине" обработки. Parsing — это, кстати, просто создание concrete sytax tree для входной строки (SQL-запроса, в данном случае).

А вот PostgreSQL учитывает их всё равно. :) Вопрос, опять-таки, в "глубине" обработки. Parsing — это, кстати, просто создание concrete sytax tree для входной строки (SQL-запроса, в данном случае).

Не совсем) он учитывает их до тех пор, пока занимается подменой понятия "prepared statement", выполняя планирование на первые пять выполнений,а потом всё, параметры ему больше не интересны

Parsing да, но есть ещеplanning

Не совсем) он учитывает их до тех пор, пока занимается подменой понятия "prepared statement", выполняя планирование на первые пять выполнений,а потом всё, параметры ему больше не интересны

А где это Вы взяли "правильное", "официальное" понятие "prepared statement", чтобы говорить о каких-то "подменах"? ;) > Parsing да, но есть еще planning Ну да, это же разные вещи. Если кто-то считает, что: prepared = parsing + planning, PostgreSQL-то тут причём? > а потом всё, параметры ему больше не интересны Или наоборот, потом интересны каждый раз.

Именно,что не интересны

>если кто-то считает, что prepared=parsing+planning ... Oracle так считает, например, и нормально перформит в этой части. Не к столу будет сказано

Именно,что не интересны

Нет. Вы неправильно понимаете, как это работает.

Спасибо, что объяснили. С вами приятно общаться. Теперь я знаю, как правильно понимать

>если кто-то считает, что prepared=parsing+planning ... Oracle так считает, например, и нормально перформит в этой части. Не к столу будет сказано

Какая нам разница, что считает Oracle (MS SQL тоже так считает, кстати)? "Официальным" термином от этого prepared statement не становится, и не даёт никому права в чём-то подозревать СУБД, которые (вот уже лет 30) считают иначе. ;)

Спасибо, что объяснили. С вами приятно общаться. Теперь я знаю, как правильно понимать

Это просто факт. Если Вам это нужно — можете поискать, как это на самом деле работает. Или спросить.

Здравствуйте всем, нужна ваша помощь :) Вообщем проблема такая - создал две базы в PGAdmin, работаю с ними через Алхимию(питон) и получается так, что из одной базы, все таблицы дублируются в другую.

_Вы не правильно понимаете, но как правильно я вам не скажу_ Ок. Считаю продолжать не имеет смысла

_Вы не правильно понимаете, но как правильно я вам не скажу_ Ок. Считаю продолжать не имеет смысла

> _Вы не правильно понимаете, Когда мне такое говорят, я, например, начинаю искать в google / документации / исходниках, если мне надо. Или спрашиваю. > но как правильно я вам не скажу_ Где я такое писал?! > Считаю продолжать не имеет смысла Да как хотите.

Здравствуйте всем, нужна ваша помощь :) Вообщем проблема такая - создал две базы в PGAdmin, работаю с ними через Алхимию(питон) и получается так, что из одной базы, все таблицы дублируются в другую.

Не может быть (по крайне мере, само по себе). Может, Вы не там или не так смотрите?

Не совсем понял про prepared statement и планинг запроса. Насколько я помню (сейчас поищу пруфы) , prepared statement не перепланируются каждый раз

Соответственно план может быть не оптимальным

Был неправ. Только парсинг не производится. Перепланирование делается

Не всегда, но делается

Был неправ. Только парсинг не производится. Перепланирование делается

Для препаред стайтментментов хранится сгенерированный generic план. При первых 5 выполнениях сравнивает среднее время custum плана и generic плана. Если первое не сильно меньше, то впоследствии всегда используется generic план(если не будет инвалидирован из-за изменения каталога). Перепланировка не делается.

Для препаред стайтментментов хранится сгенерированный generic план. При первых 5 выполнениях сравнивает среднее время custum плана и generic плана. Если первое не сильно меньше, то впоследствии всегда используется generic план(если не будет инвалидирован из-за изменения каталога). Перепланировка не делается.

А если сильно больше — то наоборот, кажется. Т.е. будет перепланироваться. И не время, а estimated cost, разве нет?

Для препаред стайтментментов хранится сгенерированный generic план. При первых 5 выполнениях сравнивает среднее время custum плана и generic плана. Если первое не сильно меньше, то впоследствии всегда используется generic план(если не будет инвалидирован из-за изменения каталога). Перепланировка не делается.

Там насколько я понял доку - там от параметров зависит - фактически от статистики. Но вам виднее

Там насколько я понял доку - там от параметров зависит - фактически от статистики. Но вам виднее

Зависит от соотношения средней оценочной стоимости 5 первых использований (custom plans) к стоимости generic plan. Далее используется либо generic, либо каждый раз custom. Кажется, так.

Наудачу )

Наудачу )

Отчасти да. Т.е., что "залипнет", custom или generic, зависит от первых выполнений. :)

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

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

хоспаде, кто-то тут говорил, что кавычка экранируется \’ а у меня заработало когда экранировал второй кавычкой ‘’

да, не очень полезная инфа, но вот мой высер, господа

@zahnik будет жить. Поприветствуем!

да, не очень полезная инфа, но вот мой высер, господа

SELECT E'a\'a', 'a''a'; И вообще, https://www.postgresql.org/docs/current/static/sql-syntax-lexical.html#SQL-SYNTAX-CONSTANTS

а, теперь все ясно

Для препаред стайтментментов хранится сгенерированный generic план. При первых 5 выполнениях сравнивает среднее время custum плана и generic плана. Если первое не сильно меньше, то впоследствии всегда используется generic план(если не будет инвалидирован из-за изменения каталога). Перепланировка не делается.

Для запросов без параметров ещё и планируется

Хотя если нет общего кэша и засада с дорогими коннектами профит - хз

Возник у меня несколько странный вопрос. Я использую pg_pathman. Имеет ли смысл устанавливать расширение на standby? Будет ли там работать partition pruning?

Возник у меня несколько странный вопрос. Я использую pg_pathman. Имеет ли смысл устанавливать расширение на standby? Будет ли там работать partition pruning?

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

А как вы его используете без установки на стендбай? ???

Возник у меня несколько странный вопрос. Я использую pg_pathman. Имеет ли смысл устанавливать расширение на standby? Будет ли там работать partition pruning?

Логическая реплика можт?

подскажите пожалуйста как выбрать 3 последние коммента к каждому посту?

Может примерно такое( делал без теста- мог с ошибками что-то написать) select * from posts_comments where id in( select m.id from (select distinct post_id from posts_comments) m join lateral(select text_message from posts_comments s where m.post_id=s.post_id order by create_date desc limit 3));

@AgapovAndrey будет жить. Поприветствуем!

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

Ну с точки зрения чтения данных из партиций он не особо нужен - читает и без них - они обычные nested tables.

Всем привет. А могу ли я воспользоваться командой COPY (select * from table ) to table1 вместо insert ?

Всем привет. А могу ли я воспользоваться командой COPY (select * from table ) to table1 вместо insert ?

create table mytable as select … from …

а copy не пойдет

а copy не пойдет

уверен, под капотом там не хуже copy

или там уже есть данные?

уверен, под капотом там не хуже copy

Мне бы как нибудь ускорить процесс вставки миллиарда записей)

или там уже есть данные?

да данные есть

Просесс вставки ограничен скоростью дисковой системы

Мне бы как нибудь ускорить процесс вставки миллиарда записей)

отключи констрейнты и индексы на момент вставки

Всем привет. А могу ли я воспользоваться командой COPY (select * from table ) to table1 вместо insert ?

Можно через stdout )

Можно через stdout )

а эта команда в фаил создаст записи или просто из запроса в таблицу вставит?

а эта команда в фаил создаст записи или просто из запроса в таблицу вставит?

Какая команда? Stdout?

Какая команда? Stdout?

да

Stdout это не команда

Stdout это не команда

ну я имею ввиду copy (select * from table ) stdout delimetr '|' создаст фаил?

Эээ...

А взять и пропрбовать?

А взять и пропрбовать?

я просто прежде чем попробовать хочу понять как это работает

Тогда достаточно заглянуть в документацию, имхо.