Re: using custom scan nodes to prototype parallel sequential scan

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: using custom scan nodes to prototype parallel sequential scan
Date: 2014-12-02 21:50:01
Message-ID: 20141202215001.GA2523@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 14, 2014 at 02:51:32PM +1300, David Rowley wrote:
> Likely for most aggregates, like count, sum, max, min, bit_and and bit_or the
> merge function would be the same as the transition function, as the state type
> is just the same as the input type. It would only be aggregates like avg(),
> stddev*(), bool_and() and bool_or() that would need a new merge function
> made... These would be no more complex than the transition functions... Which
> are just a few lines of code anyway.
>
> We'd simply just not run parallel query if any aggregates used in the query
> didn't have a merge function.
>
> When I mentioned this, I didn't mean to appear to be placing a road block.I was
> just bringing to the table the information that COUNT(*) + COUNT(*) works ok
> for merging COUNT(*)'s "sub totals", but AVG(n) + AVG(n) does not.

Sorry, late reply, but, FYI, I don't think our percentile functions
can't be parallelized in the same way:

test=> \daS *percent*
List of aggregate functions
Schema | Name | Result data type | Argument data types | Description
------------+-----------------+--------------------+----------------------------------------------+-------------------------------------
pg_catalog | percent_rank | double precision | VARIADIC "any" ORDER BY VARIADIC "any" | fractional rank of hypothetical row
pg_catalog | percentile_cont | double precision | double precision ORDER BY double precision | continuous distribution percentile
pg_catalog | percentile_cont | double precision[] | double precision[] ORDER BY double precision | multiple continuous percentiles
pg_catalog | percentile_cont | interval | double precision ORDER BY interval | continuous distribution percentile
pg_catalog | percentile_cont | interval[] | double precision[] ORDER BY interval | multiple continuous percentiles
pg_catalog | percentile_disc | anyelement | double precision ORDER BY anyelement | discrete percentile
pg_catalog | percentile_disc | anyarray | double precision[] ORDER BY anyelement | multiple discrete percentiles

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-12-02 22:02:07 Re: 9.2 recovery/startup problems
Previous Message Peter Geoghegan 2014-12-02 21:21:34 Re: B-Tree support function number 3 (strxfrm() optimization)