On 2016-05-11 03:20:12 +0300, Ants Aasma wrote: > On Tue, May 10, 2016 at 7:56 PM, Robert Haas <robertmh...@gmail.com> wrote: > > On Mon, May 9, 2016 at 8:34 PM, David Rowley > > <david.row...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers