1 |
How did I decide to remove functional interface and instead go with |
2 |
SFRM_Materialize? Well, I benchmarked both implementations: |
3 |
|
4 |
Benchmark: timing 1000 iterations of 0_old, 1_new, 2_old, 3_new, 4_old, 5_new... |
5 |
0_old: 11 wallclock secs ( 2.83 usr + 0.05 sys = 2.88 CPU) @ 347.22/s (n=1000) |
6 |
1_new: 9 wallclock secs ( 1.91 usr + 0.05 sys = 1.96 CPU) @ 510.20/s (n=1000) |
7 |
2_old: 10 wallclock secs ( 2.61 usr + 0.05 sys = 2.66 CPU) @ 375.94/s (n=1000) |
8 |
3_new: 10 wallclock secs ( 1.93 usr + 0.04 sys = 1.97 CPU) @ 507.61/s (n=1000) |
9 |
4_old: 13 wallclock secs ( 2.66 usr + 0.05 sys = 2.71 CPU) @ 369.00/s (n=1000) |
10 |
5_new: 12 wallclock secs ( 1.96 usr + 0.03 sys = 1.99 CPU) @ 502.51/s (n=1000) |
11 |
|
12 |
|
13 |
If you want to re-create this benchmark on your configuration, checkout |
14 |
revision between 19 and 24 because revision 25 obsoleted (and removed) old |
15 |
version of function. |
16 |
|
17 |
Have also in mind, that old API always fetched 6 attributes (4 found output |
18 |
and 2 for debug) while new API fetched just one for this benchmark. |
19 |
|
20 |
Each attribute fetch decrease performance for about 20 transactions in |
21 |
second, so specifying many unneeded attributes isn't free. That's why new API |
22 |
has attribute specification - both for performance and usability. |
23 |
|
24 |
And at end, a well-known secret: since we are using materialized views |
25 |
(which take place in PostgreSQL sort memory), increasing sort_mem parameter in |
26 |
postgresql.conf will dramatically increase performance. |