ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Prepare в plpgsql - нужен или нет?
10 сообщений из 10, страница 1 из 1
Prepare в plpgsql - нужен или нет?
    #38516257
Hawkmoon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hawkmoon
Участник
Читал книжку по ораклу. Решил проверить то же самое в Postgre.

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
CREATE OR REPLACE FUNCTION insert_slow()
  RETURNS void AS
$BODY$
declare
  i integer;
begin 
  for i in 1..100000
  loop
	execute 'insert into t(x) values('||i::text||')';
  end loop;
end;



Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
CREATE OR REPLACE FUNCTION insert_fast()
  RETURNS void AS
$BODY$
declare
  i integer;
begin 
  for i in 1..100000
  loop
	execute 'INSERT INTO t(x) VALUES($1)' using i;
  end loop;
end;



Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
CREATE OR REPLACE FUNCTION insert_fast2()
  RETURNS void AS
$BODY$
declare
  i integer;
begin 
  PREPARE t_plan (int) AS
    INSERT INTO t(x) VALUES($1);
  for i in 1..100000
  loop
	execute t_plan(i);
  end loop;
end;



Результаты:
а. Запросы 1 и 2 выполнились за одинаковое время
б. Запрос 3 (insert_fast2) не выполняется (на основании якобы того, что в plpgsql все операторы проходят прекомпиляцию, что явно противоречит с результатом п. а)
...
Рейтинг: 0 / 0
30.12.2013, 22:03:24
| Ответить | Цитировать | Написать  
Prepare в plpgsql - нужен или нет?
    #38516258
Hawkmoon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hawkmoon
Участник
На всякий случай: одинаковое время - это 10 секунд, что чуть больше чем <Self_censored>.
При том что в случае препарации ожидались времена в миллисекунды.

И в этом большое несчастье.

Что я не понимаю?
...
Рейтинг: 0 / 0
30.12.2013, 22:07:21
| Ответить | Цитировать | Написать  
Prepare в plpgsql - нужен или нет?
    #38516281
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
Hawkmoon,

http://www.postgresql.org/docs/9.2/static/sql-prepare.html

и
http://www.postgresql.org/docs/9.3/static/plpgsql-overview.html
40.1.1. Advantages of Using PL/pgSQL

внутри обычного плпгсикуеля уже планы, которые строятся при первом вызове функции внутри сессии
...
Рейтинг: 0 / 0
30.12.2013, 23:16:46
| Ответить | Цитировать | Написать  
Prepare в plpgsql - нужен или нет?
    #38516282
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
http://www.postgresql.org/docs/9.3/static/plpgsql-implementation.html#PLPGSQL-PLAN-CACHING
...
Рейтинг: 0 / 0
30.12.2013, 23:18:46
| Ответить | Цитировать | Написать  
Prepare в plpgsql - нужен или нет?
    #38516500
Hawkmoon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hawkmoon
Участник
Misha Tyurin,

За ссылки спасибо, почитаю. Но т.к. много буков - только на выходных.

Вопрос не снимается - аналогичная операция на Oracle занимает 100 миллисек или 10 сек, в зависимости от того, используем параметр или конкатенируем выражение.
Аргументируется это тем, что в случае подстановок не надо заново компилировать разбор.

Поэтому, чисто по экспериментальным данным в PG (10 сек vs 10 сек), возникает предположение, что компиляция в pgplsql происходит всегда.

Проверить это предположение не смог, т.к. не разобрался, как сделать аналог средствами чистого SQL:
сначала
PREPARE t_plan (int) AS ...

А затем EXECUTE t_plan, но в сочетание с generate_series.
Думал час, тыкался, без эффекта - ничего не сконструировал
...
Рейтинг: 0 / 0
31.12.2013, 13:18:09
| Ответить | Цитировать | Написать  
Prepare в plpgsql - нужен или нет?
    #38516528
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
Hawkmoon,



а чем собственно не устраивает просто

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
CREATE OR REPLACE FUNCTION insert_fast()
  RETURNS void AS
$BODY$
declare
  i integer;
begin 
  for i in 1..100000
  loop
	INSERT INTO t(x) VALUES(i);
  end loop;
end;



и план кешироваться будет нормально и время работы (у меня) 450ms
...
Рейтинг: 0 / 0
31.12.2013, 14:11:44
| Ответить | Цитировать | Написать  
Prepare в plpgsql - нужен или нет?
    #38516560
Hawkmoon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hawkmoon
Участник
Maxim Boguk,

Непонятно, происходит препарация (компиляция т.е.) запроса или нет:

Потому как
Код: sql
1.
execute 'insert into t(x) values('||i::text||')'


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

и при этом
Код: sql
1.
execute 'insert into t(x) values($1)' using i


идет за то же самое время.

Я понял замечание про
INSERT INTO t(x) VALUES(i)
но хотелось бы разобраться именно с execute'ом и $1.

Вопрос принципиальный. Продолжу числа 2-го.
...
Рейтинг: 0 / 0
31.12.2013, 15:22:21
| Ответить | Цитировать | Написать  
Prepare в plpgsql - нужен или нет?
    #38516600
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
Hawkmoon,

execute в pl/pgsql ВСЕГДА парсится вне зависимости от того используте вы USGING или нет
и обойти это ограничение фактически не возможно (и в доке об этом явно и однозначно написано).

execute - last restort measure для тех случаев когда по другому никак вообще (динамические запросы)
выполнять через execute статические запросы не надо никогда и ни в каком случае
...
Рейтинг: 0 / 0
31.12.2013, 16:17:34
| Ответить | Цитировать | Написать  
Prepare в plpgsql - нужен или нет?
    #38516839
Мужик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мужик
Участник
Maxim BogukHawkmoon,

execute в pl/pgsql ВСЕГДА парсится вне зависимости от того используте вы USGING или нет
и обойти это ограничение фактически не возможно (и в доке об этом явно и однозначно написано).

execute - last restort measure для тех случаев когда по другому никак вообще (динамические запросы)
выполнять через execute статические запросы не надо никогда и ни в каком случае
Насколько я помню, EXECUTE USING ввели как раз по многочисленным просьбам инвалидировать планы запросов, против чего был Tom. В итоге ввели как компромисное решение.
И это вовсе не last resort, а обычный use case, когда план запроса сильно зависит от входных параметров. Простые INSERT к этому случаю, понятное дело, не относятся.
...
Рейтинг: 0 / 0
01.01.2014, 19:20:23
| Ответить | Цитировать | Написать  
Prepare в plpgsql - нужен или нет?
    #38521684
Hawkmoon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hawkmoon
Участник
Мужик,

Инвалидировать = "вымывать из кеша" ?
Тогда высказывание имеет смысл с точностью до наоборот, как мне кажется.
...
Рейтинг: 0 / 0
10.01.2014, 12:17:57
| Ответить | Цитировать | Написать  
10 сообщений из 10, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Prepare в plpgsql - нужен или нет?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=53&msg=38516282&tid=1998906]:
 0ms
get settings:
 9ms
get forum list:
 20ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 205ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 48ms
get tp. blocked users:
 1ms
others: 193ms
total:  496ms
созд. / загр.: 496ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]