ExecProject() in advance_aggregates() is rather expensive

Поиск
Список
Период
Сортировка
От Andres Freund
Тема ExecProject() in advance_aggregates() is rather expensive
Дата
Msg-id 20160519175727.ymv2y5tye4qgcmqx@alap3.anarazel.de
обсуждение исходный текст
Список pgsql-hackers
Hi,

Since 34d26872ed816b2 ("Support ORDER BY within aggregate function
calls") we use ExecProject() and a slot within advance_aggregates().
Previous to that patch we simply directly filled fcinfo.args with
ExecEvalExpr().

According to my profiles the new way generally is considerably slower,
but especially so if there are a number of aggregates (which each have a
separate projection).

E.g. the profile of
SELECT SUM(abalance), AVG(abalance), count(*) FROM pgbench_accounts;
starts with
+   18.85%  postgres  postgres           [.] ExecProject
+   10.14%  postgres  postgres           [.] advance_aggregates
+    9.50%  postgres  postgres           [.] advance_transition_function
+    8.92%  postgres  postgres           [.] slot_getsomeattrs


I wonder if we should add a ExecEvalExpr() and/or try to build a single
projection that can compute the input for all transition functions at
once.

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Parallel query
Следующее
От: Michael Paquier
Дата:
Сообщение: Typo in 001_initdb.pl