I was doing some memory testing under fractional CPU allocations and it became
painfully obvious that the repeat() function needs CHECK_FOR_INTERRUPTS().
I exchanged a few emails offlist with Tom about it, and (at the risk of putting
words in his mouth) he agreed and felt it was a candidate for backpatching.
Very small patch attached. Quick and dirty performance test:
explain analyze SELECT repeat('A', 300000000);
explain analyze SELECT repeat('A', 300000000);
explain analyze SELECT repeat('A', 300000000);
With an -O2 optimized build:
Without CHECK_FOR_INTERRUPTS
Planning Time: 1077.238 ms
Execution Time: 0.016 ms
Planning Time: 1080.381 ms
Execution Time: 0.013 ms
Planning Time: 1072.049 ms
Execution Time: 0.013 ms
With CHECK_FOR_INTERRUPTS
Planning Time: 1078.703 ms
Execution Time: 0.013 ms
Planning Time: 1077.495 ms
Execution Time: 0.013 ms
Planning Time: 1076.793 ms
Execution Time: 0.013 ms
While discussing the above, Tom also wondered whether we should add unlikely()
to the CHECK_FOR_INTERRUPTS() macro.
Small patch for that also attached. I was not sure about the WIN32 stanza on
that (to do it or not; if so, what about the UNBLOCKED_SIGNAL_QUEUE() test).
I tested as above with unlikely() and did not see any discernible difference,
but the added check might improve other code paths.
Comments or objections?
Thanks,
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development