Re: asynchronous and vectorized execution - Mailing list pgsql-hackers

From Andres Freund
Subject Re: asynchronous and vectorized execution
Date
Msg-id 20160511005213.xrk3wxbwvoqyz47j@alap3.anarazel.de
Whole thread Raw
In response to Re: asynchronous and vectorized execution  (Ants Aasma <ants.aasma@eesti.ee>)
List pgsql-hackers
On 2016-05-11 03:20:12 +0300, Ants Aasma wrote:
> On Tue, May 10, 2016 at 7:56 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> > On Mon, May 9, 2016 at 8:34 PM, David Rowley
> > <david.rowley@2ndquadrant.com> wrote:
> > I don't have any at the moment, but I'm not keen on hundreds of new
> > vector functions that can all have bugs or behavior differences versus
> > the unvectorized versions of the same code.  That's a substantial tax
> > on future development.  I think it's important to understand what
> > sorts of queries we are targeting here.  KaiGai's GPU-acceleration
> > stuff does great on queries with complex WHERE clauses, but most
> > people don't care not only because it's out-of-core but because who
> > actually looks for the records where (a + b) % c > (d + e) * f / g?
> > This seems like it has the same issue.  If we can speed up common
> > queries people are actually likely to run, OK, that's interesting.
> 
> I have seen pretty complex expressions in the projection and
> aggregation. Couple dozen SUM(CASE WHEN a THEN b*c ELSE MIN(d,e)*f
> END) type of expressions. In critical places had to replace them with
> a C coded function that processed a row at a time to avoid the
> executor dispatch overhead.

I've seen that as well, but Was it the actual fmgr indirection causing
the overhead, or was it ExecQual/ExecMakeFunctionResultNoSets et al?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: ALTER TABLE lock downgrades have broken pg_upgrade
Next
From: Fabrízio de Royes Mello
Date:
Subject: Re: Does Type Have = Operator?