| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Kevin Grittner <kgrittn(at)ymail(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila(at)enterprisedb(dot)com>, Simon Riggs <simon(dot)riggs(at)2ndquadrant(dot)com> |
| Subject: | Re: The Future of Aggregation |
| Date: | 2015-06-11 13:49:30 |
| Message-ID: | CA+TgmoZwPzWkaZs+bns-kDuzpAL1WDYMoBUaguFvrokKPHG6NA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jun 9, 2015 at 11:00 AM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> Uh, this also requires serialization and deserialization of non-
> finalized transition state, no?
A bunch of this stuff does, but I recently had a Brilliant Insight: we
don't need to add a new method for serializing and deserializing
transition functions. We can already do that: to serialize an
aggregate transition state, you run it through the typoutput (or
typsend) function and to deserialize it, you run it through the
typinput (or typreceive) function. The only problem is that we have
some aggregate functions that use an internal type. Those could,
however, be changed: we could invent new types for each aggregate that
uses a distinctive internal representation, rather than lumping it all
under internal, and then give those types real input and output
functions. That way, we don't really need to invent anything new
here.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2015-06-11 13:51:42 | Re: DBT-3 with SF=20 got failed |
| Previous Message | Fujii Masao | 2015-06-11 13:45:04 | Re: minor issues in pg_rewind |