From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | repeat() function, CHECK_FOR_INTERRUPTS(), and unlikely() |
Date: | 2020-05-12 12:06:58 |
Message-ID: | 8692553c-7fe8-17d9-cbc1-7cddb758f4c6@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
repeat-check4int.diff | text/x-patch | 844 bytes |
unlikely-check4int.diff | text/x-patch | 953 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2020-05-12 12:54:17 | Re: making update/delete of inheritance trees scale better |
Previous Message | Amit Kapila | 2020-05-12 11:09:35 | Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions |