Зависит от много чего... Select field from table where field=value в общем случае

Если это fk  или unique то проверка вообще на уровне движка будет

Спасибо, сделал иначе: 'SELECT COUNT(*) FROM tasks WHERE ...'

Гляньте ещё вот это https://www.techonthenet.com/postgresql/exists.php

у меня с английским плохо

Если речь идет о скорости то предложенный вам вариант с условием по WHERE EXISTS(SELECT 1 FROM ГДЕИЩУ WHERE ЧТО ИЩУ)  будет однозначно быстрее COUNT так как EXISTS тупо выходит по достижении первого результата в то время как COUNT обработает все записи.

Благодарю

1 можно не писать :)

(other/total) возвращает integer, и результат кратный 100, это не то
Да и вообще вопрос был не об этом
Эти три столбца я вычисляю по отдельности, и результат может получится такой:
13.50%, 68.62%, 17.89% = 100.1%
Как то можно их "объединить", чтобы 100% правильно распределилось, причем с округлением до 2 знаков?

Общее правило для такого расчета это округлять только конечный результат. Ну и проверьте, что интервалы расчетов не пересекаются

Во-первых, правильного вообще варианта здесь быть не можэт -- например, если в трёх категориях одинаковое количество людей, то ты не сможэшь подобрать три одинаковых значения процэнтов с точностью две цыфры после запятой, чтобы в сумме они дали 100%.
То есть или там у одного из них будет 33.34%, хотя во всех категориях одно и тожэ количество людей, или сумма будет 99.99%.

Во-вторых, если устраивает неправильный -- то можно считать количество людей нарастающим итогом (то есть у первой категории -- только первую, у второй -- первую+вторую, у третьей -- 1ую+2ую+3ю), потом вычислять для этого нарастающего итога процэнты и вычитать процэнты предыдущей категории. Сумма будет в итоге 100%, отличия от математически-правильных чисел в пределах точности округления.

Много разговоров шло о выпуска версии 13 об упреждающей выборке. Я не утверждаю что понял  верно смысл реализации данной концепции но у меня сложилось мнение что зерно данного решения состоит в предварительном расчете полей непосредственно участвующих в связывании JOIN, условиях WHERE и блоках фильтрации.  Возможно я не прав, в любом случае данные новшества в итоге не попали в 13 версию.  И вообще ветка данная как то заглохла. Может кто то более компетентный в курсе что то делается в этом направлении? Поясню зачем? Для тех кому не лезут в голову многоэтажные JOIN разделить на view можно но всегда есть НО в отсутствие функций принимающих кортежи разбиение на VIEW при JOIN без упреждающей выборки существенно снижает производительность.  Я обошел данное ограничение воспользовавшись массивами выборки через функции ANY в принимающих функциях получив хорошие результаты в итоговых выражениях, что вызывает другой вопрос, Как это отразится на глубине выборки, насколько массивы отличаются от списка кортежей.  в перспективе до 10 тысяч записей я не вижу проблем. Но люди тут показывают такие базы которых я не видел с 1998 года 🙈, не думаю что мой движок в принципе применим для таких решений но хотелось бы понять при использовании массивов я упрусь в их размер относительно списка  кортежей или в плане реализации это все таки родственные сущности?

Ну да, не подумал о таком варианте. Спасибо

Для примера приведу один из вариантов функции ограничения выборки которые я использую : CREATE OR REPLACE FUNCTION bpd.int_object_ext_prop_by_id_object_array(object_array bigint[])
RETURNS SETOF bpd.int_object_ext
LANGUAGE plpgsql
STABLE PARALLEL SAFE
AS $function$
DECLARE
BEGIN
   RETURN QUERY SELECT
   op.id_object_carrier AS id,
   array_agg((op.*)::bpd.cobject_prop) AS property_list
   FROM bpd.vobject_prop op
   WHERE (op.id_object_carrier = ANY(object_array))
   GROUP BY op.id_object_carrier;
END;
$function$;
-- -------------------------------------------------------------

Подождите... о чём конкретно речь (а то как-то туманно)?
Есть ссылки на threads в -hackers, или на commitfest?

Я поищу но речь идет о частичном расчете rows при первичном связывании таблиц во всяком случае я так это понял.

Это как то засело у меня в голове и я разделил эти этапы при помощи массивов выборки и функции ANY но у меня остались сомнения по поводу ограничения размеров выборки. При этом тесты показывают экспоненциальный прирост производительности, что говорит о том что чем точнее запрос тем быстрее он обрабатывается. Меня это устраивает, но не хотелось бы упереться  в какое то ограничения размера массива я не могу это оценить.

x1 + x2 + x3 =100%

Находишь по своей формуле X1 и X2

А после этого просто делаешь 100-x1-x2 = x3 ))))

Да, так и сделал, спасибо)