Re: [GENERAL] Performance options for CPU bound multi-SUM query

2016-01-27 Thread David Rowley
On 28 January 2016 at 08:41, Matt wrote: > Moving from NUMERIC to FLOAT(8) did indeed lower query times by about 20%. > > I will try fixeddecimal and agg() as time permits. That's surprisingly little gain. Please note that you'll not gain any further improvements from the fixeddecimal type than y

Re: [GENERAL] Performance options for CPU bound multi-SUM query

2016-01-27 Thread Matt
Moving from NUMERIC to FLOAT(8) did indeed lower query times by about 20%. I will try fixeddecimal and agg() as time permits. On 25 Jan 2016, at 4:44, David Rowley wrote: On 25 January 2016 at 15:45, Matt wrote: I have a warehousing case where data is bucketed by a key of an hourly timesta

Re: [GENERAL] Performance options for CPU bound multi-SUM query

2016-01-25 Thread David Rowley
On 25 January 2016 at 15:45, Matt wrote: > I have a warehousing case where data is bucketed by a key of an hourly > timestamp and 3 other columns. In addition there are 32 numeric columns. The > tables are partitioned on regular date ranges, and aggregated to the lowest > resolution usable. > > Th

Re: [GENERAL] Performance options for CPU bound multi-SUM query

2016-01-25 Thread Andreas Kretschmer
Matt wrote: > I have a warehousing case where data is bucketed by a key of an hourly > timestamp and 3 other columns. In addition there are 32 numeric columns. The > tables are partitioned on regular date ranges, and aggregated to the lowest > resolution usable. > > The principal use case is to

[GENERAL] Performance options for CPU bound multi-SUM query

2016-01-24 Thread Matt
I have a warehousing case where data is bucketed by a key of an hourly timestamp and 3 other columns. In addition there are 32 numeric columns. The tables are partitioned on regular date ranges, and aggregated to the lowest resolution usable. The principal use case is to select over a range of