Matt <bsg...@gmail.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° -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
