Re: Optimizing numeric SUM() aggregate

Поиск
Список
Период
Сортировка
От Andrew Borodin
Тема Re: Optimizing numeric SUM() aggregate
Дата
Msg-id CAJEAwVEjAjQs4etk5qAyzrcNHV2c=fdrEUqkTgYcRHTFAejcDQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Optimizing numeric SUM() aggregate  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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@sss.pgh.pa.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.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Aleksander Alekseev
Дата:
Сообщение: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)
Следующее
От: Kevin Grittner
Дата:
Сообщение: Re: "Strong sides of MySQL" talk from PgDay16Russia, translated