Optimize scram_SaltedPassword performance

From: Zixuan Fu <r33s3n6(at)gmail(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: Zixuan Fu <r33s3n6(at)gmail(dot)com>
Subject: Optimize scram_SaltedPassword performance
Date: 2025-02-03 07:11:48
Message-ID: Z6BsNAadbID+k2L4@bass1
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Hackers,

While profiling a program with `perf`, I noticed that `scram_SaltedPassword`
consumed more CPU time than expected. After some investigation, I found
that the function performs many HMAC iterations (4096 rounds for
SCRAM-SHA-256), and each iteration reinitializes the HMAC context, causing
excessive overhead.

OpenSSL has an optimization for this case: when the key remains the
same, the HMAC context can be reused with a lightweight state reset by
passing NULL as the key. To take advantage of this, I introduced
`pg_hmac_reuse()`, which replaces the key with NULL when OpenSSL is used.

With this change, the performance improves by approximately **4x** (reducing
execution time from 4ms to 1ms). The built-in PostgreSQL HMAC implementation
does not support context reuse, and modifying it would require substantial
changes. Therefore, `pg_hmac_reuse()` simply calls `pg_hmac_init()` in that
case, maintaining the existing logic.

Regards,

Zixuan

Attachment Content-Type Size
v1-0001-Optimize-scram_SaltedPassword-with-HMAC-context-reuse.patch text/x-patch 3.4 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Vladlen Popolitov 2025-02-03 07:15:59 Re: SQL/JSON json_table plan clause
Previous Message Antonin Houska 2025-02-03 07:01:45 Re: why there is not VACUUM FULL CONCURRENTLY?