From: | Andreas Kretschmer <akretschmer(at)spamfence(dot)net> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Performance options for CPU bound multi-SUM query |
Date: | 2016-01-25 08:04:36 |
Message-ID: | 20160125080436.GA10459@tux |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Matt <bsg075(at)gmail(dot)com> 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 select over a range of dates or hours, filter by
> the other key columns, and SUM() all 32 of the other columns. The execution
> plan shows the primary key index limits row selection efficiently, but the
> query appears CPU bound in performing all of those 32 SUM() aggregates.
>
> I am looking at a couple of distributed PostgreSQL forks, but until those reach
> feature parity with 9.5 I am hoping to stay with single node PostgreSQL.
>
> Are there any other options I can use to improve query times?
Maybe cybertec's agg() - patch, see
http://www.cybertec.at/postgresql_produkte/agg-parallele-aggregierungen-fuer-postgresql/
(and ask Hans for an english docu!)
But, i see, it needs 9.5.
Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°
From | Date | Subject | |
---|---|---|---|
Next Message | Vik Fearing | 2016-01-25 08:48:01 | Re: TABLESAMPLE usage |
Previous Message | Thomas Kellerer | 2016-01-25 06:53:29 | Re: 9.5 new features |