From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Improve hash-agg performance |
Date: | 2016-12-01 01:50:38 |
Message-ID: | 20161201015038.7uh2uevkrorcihup@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2016-11-03 04:07:21 -0700, Andres Freund wrote:
> Hi,
>
> There's two things I found while working on faster expression
> evaluation, slot deforming and batched execution. As those two issues
> often seemed quite dominant cost-wise it seemed worthwhile to evaluate
> them independently.
>
> 1) We atm do one ExecProject() to compute each aggregate's
> arguments. Turns out it's noticeably faster to compute the argument
> for all aggregates in one go. Both because it reduces the amount of
> function call / moves more things into a relatively tight loop, and
> because it allows to deform all the required columns at once, rather
> than one-by-one. For a single aggregate it'd be faster to avoid
> ExecProject alltogether (i.e. directly evaluate the expression as we
> used to), but as soon you have two the new approach is faster.
>
> 2) For hash-aggs we right now we store the representative tuple using
> the input tuple's format, with unneeded columns set to NULL. That
> turns out to be expensive if the aggregated-on columns are not
> leading columns, because we have to skip over a potentially large
> number of NULLs. The fix here is to simply use a different tuple
> format for the hashtable. That doesn't cause overhead, because we
> already move columns in/out of the hashslot explicitly anyway.
I pushed a bit more polished versions of these.
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Karlsson | 2016-12-01 02:17:26 | Re: pgcrypto compilation error due to stack-allocated EVP_CIPHER_CTX |
Previous Message | Andres Freund | 2016-12-01 01:48:26 | pgcrypto compilation error due to stack-allocated EVP_CIPHER_CTX |