Deduplicate aggregates and transition functions in planner

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Deduplicate aggregates and transition functions in planner
Date: 2020-10-28 19:10:41
Message-ID: b2e3536b-1dbc-8303-c97e-89cb0b4a9a48@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Currently, ExecInitAgg() performs quite a lot of work, to deduplicate
identical Aggrefs, as well as Aggrefs that can share the same transition
state. That doesn't really belong in the executor, we should perform
that work in the planner. It doesn't change from one invocation of the
plan to another, and it would be nice to reflect the state-sharing in
the plan costs.

Attached is a patch to do that. It adds two new fields to Aggref,
'aggno' and 'aggtransno', to identify the unique aggregate and
transition states. The duplicates are detected, and those filled in,
early in the planning. Aside from those fields, the planner doesn't pass
any other new information to to the executor, so the the executor still
has to do syscache lookups to get the transition, combine etc. functions.

I tried a bigger refactoring at first, to pass more information from the
planner to the executor, but the patch grew really large before I got
very far with it. So as the first step, I think we should apply the
attached patch, and further refactoring can be done after that, if it
seems worthwhile.

There is one known regression failure, in the 'partition_aggregate'
test, which is caused by a plan change in one of the queries. The query
contains a few aggregates, and the planner now detects that some of them
are identical, which changed the cost estimates, making a different plan
look cheaper. That's easy to fix, although I'm not sure yet if we should
accept the new plan, or change the query to still get the old plan.

- Heikki

Attachment Content-Type Size
v1-0001-Move-peragg-and-pertrans-duplicate-finding-to-pre.patch text/x-patch 75.6 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2020-10-28 19:12:01 Re: Add important info about ANALYZE after create Functional Index
Previous Message David G. Johnston 2020-10-28 19:07:52 Re: Add important info about ANALYZE after create Functional Index