Здравствуйте! Выполняю запрос, в результате по одному столбцу есть лишние данные,

можно ли часть отбросить?


<span style="background-color: lightsteelblue; color: black;" xmlns="http://www.w3.org/1999/xhtml">101 - Обследованные добровольно по инициативе пациента (при отсутствии ругих причин обследования).</span>

и оставить только
"101 - Обследованные добровольно по инициативе пациента (при отсутствии ругих причин обследования)."

Stanislav Kulikov
снова вопрос вот поле комментарий где-то выбиралос...

а SELECT comments, count(*) FROM table GROUP BY comments не подходит? или я чего не понял?

я такую выборку как в таблице стремлюсь получить

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

если "ещё и", то ртфм roll up, grouping set, cube для груп бай

надо подумать, сразу с ходу не могу подсказать

Stanislav Kulikov
снова вопрос вот поле комментарий где-то выбиралос...

если правильно понял, то что-то типа такого select t1.id, count(*), sum((t1.sex = 1 and t1.age < 14)::INT) child_male_count, sum((t1.sex = 0 and t1.age < 14)::INT) child_female_count, sum((t1.sex = 1 and t1.age between 15 and 17)::INT) teenager_male_count, sum((t1.sex = 0 and t1.age between 15 and 17)::INT) teenager_female_count, sum((t1.sex = 1 and t1.age > 18)::INT) adult_male_count, sum((t1.sex = 0 and t1.age > 18)::INT) adult_female_count from (values (1, 2, 0), (1, 3, 1), (1, 4, 1) ) t1 (id, age, sex) group by t1.id

ООо, спасибо, поразбираюсь У меня сейчас вот такой запрос получился под один код select count(DISTINCT i.cartnum ) AS "ВСЕГО УНИКАЛЬНЫХ ЛЮДЕЙ", count(case when p.sex LIKE ('М') and date_part('year', age(current_date, p.birthday)) > 17 then 1 end) AS "МУЖЧИНЫ", count(case when p.sex LIKE ('Ж') and date_part('year', age(current_date, p.birthday)) > 17 then 1 end ) AS "ЖЕНЩИНЫ", count(case when date_part('year', age(current_date, p.birthday)) < 15 then 1 end) AS "ДЕТИ", count(case when date_part('year', age(current_date, p.birthday)) > 14 and date_part('year', age(current_date, p.birthday)) < 18 then 1 end) AS "ПОДРОСТКИ", count(*) AS "ВСЕГО УСЛУГ", count(DISTINCT case when rf.flag_name LIKE ANY(ARRAY['Обнар%','обнар%','%+%','%пол%','сом%','%больш%','%омни%','%овторить%','%еденич%','%поры%','%ицели%']) then i.cartnum end) AS "ПОЛОЖИТЕЛЬНЫХ" from lis.scheduled_profiles sp join gis.invest i on sp.counter = i.counter join gis.pats p on p.cartnum = i.cartnum join lis.scheduled_invests si on si.scheduled_profile = sp.scheduled_profile join lis.scheduled_tests st on st.scheduled_invest = si.scheduled_invest join lis.rt_test_properties tp on tp.test = st.test join lis.raw_results r on r.raw_result = st.raw_result left join lis.er_reference_flags rf on rf.reference_flag = r.reference_flag left join lis.er_reference_ranges err on err.reference_range = r.reference_range join refs.rtusers u on i.creator_user = u.userid join refs.rtuserrevisions ur on ur.userid = u.id join refs.rtuserprops up on up.revisionid = ur.revisionid where sp.authorized_time BETWEEN to_date('2021-01-01','YYYY-MM-DD') AND to_date('2021-12-31','YYYY-MM-DD') and (sp.resid LIKE ANY(ARRAY['A26.06.049.001']) and i.comments LIKE ('%101%') )

👏 красиво

case это плохо, не стоит по возможности его исполдьзовать

спс, постгрес учит мыслить нестандартно 😁

согласен

А чем плохо?

Аргументы? Кастинг булевого выражения в инт, с точки зрения читабельности кода - это просто ужас по сравнению с case. Если, конечно, вы не пишете код, который не требуется поддерживать. Если надо посчитать число строе, удовлетворяющих условию, гораздо правильнее использовать count(*) filter (where условие)

Сталкивались с проблемами производительности при использовании case. А про filter вылетело из головы. Спасибо за напоминание.

Вот прямо при прямом проходе? Или case использовался в предикатах для join-а табличек? Что касается оптимизации - как минимум, при построении плана, case может эффективно удаляться, если на этом этапе однозначно определена ветка (мы такое используем для применения динамических условий, а также для замены nullif, который почему-то не вычисляется на этапе построения плана (недавно приняли коммит, который фиксил эту проблему)), так что case - довольно полезная конструкция. А вообще, было бы интересно проверить, обрабатывается ли case при использовании jit-оптимизации выражений. Если нет - тогда согласен, могут быть проблемы с его использованием.