Гость
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / подскажите а можно ли этот запрос сделать компактнее/шустрее? / 3 сообщений из 3, страница 1 из 1
21.10.2017, 15:42
    #39539889
MMM_Corp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
подскажите а можно ли этот запрос сделать компактнее/шустрее?
есть такая функцыя бронирования номера отеля

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
CREATE OR REPLACE FUNCTION public.book_number (
  iorders_data_id integer,
  start_date date,
  idays smallint,
  ihotel_id integer,
  iitems_cats_id integer,
  icurrency_id smallint = 0
)
RETURNS integer AS
$body$
declare 
	items_id_start_booking INTEGER = 0;
    booking_numbers_count INTEGER = 1;	-- к-во номеров для бронирования (врятли будет использоватся)
    end_date date;	-- дата окончания бронирования
BEGIN
end_date = (start_date + (idays-1 || ' day')::interval)::date;


RAISE NOTICE 'iorders_data_id: %', iorders_data_id;
RAISE NOTICE 'start_date: %', start_date;
RAISE NOTICE 'idays: %', idays;
RAISE NOTICE 'ihotel_id: %', ihotel_id;
RAISE NOTICE 'iitems_cats_id: %', iitems_cats_id;
RAISE NOTICE 'icurrency_id: %', icurrency_id;


-- получаем items.id которые можем бронировать
select   
	id into items_id_start_booking    
from
  (
  select 
      n.id
      , n.g
      -- n.*, w.*
  from 
  	(SELECT * FROM public.get_items_matrix(start_date, idays, ihotel_id, iitems_cats_id)) as n
  left join 
      worktop w on 
          w.items_id = n.id 
      and w.ddate = n.g
  -- нам нужны только номера полностью без заказов на весь период заказа без разрывов    
  where 
      w.orders_data_id is null
  ) as s

-- групируем по номерах
group by s.id
-- только полностью свободных дней
HAVING count(*)=idays
ORDER BY random()	-- перемешиваем
limit booking_numbers_count;	-- берём только один номер, больше нам не нужно

IF items_id_start_booking is NULL THEN
	RAISE EXCEPTION 'free items not found'; -- свободных номеров нет
END IF; 

insert into worktop(orders_data_id, ddate, status_id, items_id)
  select 
  	iorders_data_id,
  	c.g,
    case 
      when c.g=start_date then 0	-- первый день бронирования
      when c.g=end_date then 1	-- последный день бронирования
      else NULL
    end,
    items_id_start_booking
  from 
  	get_calendar(start_date, end_date) as c;

RETURN items_id_start_booking;

END;
$body$
LANGUAGE 'plpgsql'
VOLATILE
CALLED ON NULL INPUT
SECURITY INVOKER
COST 100;



все работает, но смущает что разбито на части, не покидает ощущение нубского кода, думаю над "WITH"
в общем посоветуйте как можно его сделать компактнее, желательно без подзапроса (вообще с подзапросами хотелось бы окончательно попрощатся, но стоит ли, возможно ли, хорошо если отправите в нужном направлении за богатими примерами, не только в разрезе простоты кода но и быстрдействия)
...
Рейтинг: 0 / 0
21.10.2017, 17:30
    #39539902
vyegorov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
подскажите а можно ли этот запрос сделать компактнее/шустрее?
MMM_Corp,

Если требуется затюнить запрос, то надо показать его “как есть” с параметрами, а также привести вывод `EXPLAIN (analyze, buffers)`.
...
Рейтинг: 0 / 0
21.10.2017, 19:04
    #39539930
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
подскажите а можно ли этот запрос сделать компактнее/шустрее?
MMM_Corp,

тут не оптимизировать надо, а сначала выправить.

беромое от берения до коммита должно лочицца. если конечно стойка не в сингл--моде работает.

а для лока групповуха не подходит. лочатся только одиночки. такие уж они в скл серьёзные.

т.е. первый запрос выбора переписать плностью -- на выборку записи (записей) не групповым запросом, с обязательным FOR UPDATE . (с проверкой отсутствия накладок либо в lateral--е [или кореляте], либо в exsists--e.

и т.д.
а насчет стиля я б не переживал. он от смыслов происходит.
...
Рейтинг: 0 / 0
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / подскажите а можно ли этот запрос сделать компактнее/шустрее? / 3 сообщений из 3, страница 1 из 1
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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