| From: | Andrew Borodin <borodin(at)octonica(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Optimizing numeric SUM() aggregate |
| Date: | 2016-07-29 12:44:14 |
| Message-ID: | CAJEAwVEjAjQs4etk5qAyzrcNHV2c=fdrEUqkTgYcRHTFAejcDQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I've tested patch with this query
https://gist.github.com/x4m/fee16ed1a55217528f036983d88771b4
Test specs were: Ubuntu 14 LTS VM, dynamic RAM, hypervisor Windows
Server 2016, SSD disk, core i5-2500. Configuration: out of the box
master make.
On 10 test runs timing of select statement: AVG 3739.8 ms, STD 435.4193
With patch applied (as is) : 3017.8 ms, STD 319.893
Increase of overflow const showed no statistically viable performance
improvement (though, I do not worth doing).
2016-07-27 17:32 GMT+05:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> For that matter, spelling INT_MAX as 0x7FFFFFF is also not per project style.
Sure, 0x7FFFFFF was not for code but for metal arithmetics. I would
even add that INT_MAX is system-dependent and varies in different
specs. I'd suggest INT32_MAX.
Best regards, Andrey Borodin, Octonica & Ural Federal University.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2016-07-29 13:17:02 | Re: "Strong sides of MySQL" talk from PgDay16Russia, translated |
| Previous Message | Aleksander Alekseev | 2016-07-29 11:15:52 | [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables) |