Re: Rethinking representation of partial-aggregate steps - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Rethinking representation of partial-aggregate steps
Date
Msg-id 20160623180112.GA204252@alvherre.pgsql
Whole thread Raw
In response to Re: Rethinking representation of partial-aggregate steps  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:

> What I'm imagining is, say,
> 
> #define AGGOP_COMBINESTATES   0x1
> #define AGGOP_SERIALIZESTATES  0x2
> #define AGGOP_DESERIALIZESTATES  0x4
> #define AGGOP_FINALIZEAGGS 0x8
> 
> typedef enum AggPartialMode
> {
>   AGGPARTIAL_SIMPLE = AGGOP_FINALIZEAGGS,
>   AGGPARTIAL_PARTIAL = AGGOP_SERIALIZESTATES,
>   AGGPARTIAL_FINAL = AGGOP_COMBINESTATES | AGGOP_DESERIALIZESTATES | AGGOP_FINALIZEAGGS
> } AggPartialMode;
> 
> #define DO_AGGPARTIAL_COMBINE(apm)  (((apm) & AGGOP_COMBINESTATES) != 0)
> #define DO_AGGPARTIAL_SERIALIZE(apm)  (((apm) & AGGOP_SERIALIZESTATES) != 0)
> #define DO_AGGPARTIAL_DESERIALIZE(apm)  (((apm) & AGGOP_DESERIALIZESTATES) != 0)
> #define DO_AGGPARTIAL_FINALIZE(apm)  (((apm) & AGGOP_FINALIZEAGGS) != 0)
> 
> 
> These enum constants satisfy the properties I mentioned before, but their
> assigned values are chosen to make the macros cheap.

Ah, sure, that makes sense.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Bug in to_timestamp().
Next
From: Tom Lane
Date:
Subject: Re: Bug in to_timestamp().