| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | ExecProject() in advance_aggregates() is rather expensive |
| Date: | 2016-05-19 17:57:27 |
| Message-ID: | 20160519175727.ymv2y5tye4qgcmqx@alap3.anarazel.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2016-05-19 18:05:15 | Typo in 001_initdb.pl |
| Previous Message | Tatsuo Ishii | 2016-05-19 15:07:15 | Parallel query |