Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance / memory usage fix: do not allocate memory in pg_tde_slot #265

Merged
merged 2 commits into from
Aug 28, 2024

Conversation

dutow
Copy link
Collaborator

@dutow dutow commented Aug 26, 2024

Until now, for some reason we allocated memory for each decrypted tuple in pg_tde_slot, and only freed all that memory when the transaction ended. This caused two issues:

  • palloc takes time, and the many small pallocs resulted in a significant performance drop in scans
  • sequential scans could potentially allocate memory to the entire table, requiring way too much memory for large tables

This allocation is most likely a leftover from before we even used slots, and handled selects differently. With slots, we don't need them at all, as slots are not expected to handle multiple tuples at the same time, only the last one.

This commit removes the palloc completely, and instead adds a single BLCKSZ array to the slot structure, which can hold any size of decrypted tuple.

To be safe, it also disables the get tuple function, forcing the core code to use copy instead when needed.

This change results in:

  1. no "memory spike" during sequential scans
  2. ~1.55x overhead instead of ~2.2x

(The TODO in slot_copytuple will be addressed in a separate commit)

@dutow dutow requested review from codeforall and dAdAbird August 26, 2024 07:36
@codeforall
Copy link
Contributor

Overall, the PR looks good. Just one minor comment. I believe we can now get rid of TdeSlotForgetDecryptedTuple function as we do not need to pfree the decrypted_tuple

dutow added 2 commits August 28, 2024 19:51
Until now, for some reason we allocated memory for each decrypted
tuple in pg_tde_slot, and only freed all that memory when the
transaction ended. This caused two issues:

* palloc takes time, and the many small pallocs resulted in a
  significant performance drop in scans
* sequential scans could potentially allocate memory to the entire
  table, requiring way too much memory for large tables

This allocation is most likely a leftover from before we even used
slots, and handled selects differently. With slots, we don't need
them at all, as slots are not expected to handle multiple tuples
at the same time, only the last one.

This commit removes the palloc completely, and instead adds a single
BLCKSZ array to the slot structure, which can hold any size of
decrypted tuple.

To be safe, it also disables the get tuple function, forcing the
core code to use copy instead when needed.

This change results in:

1. no "memory spike" during sequential scans
2. ~1.55x overhead instead of ~2.2x

(The TODO in slot_copytuple will be addressed in a separate commit)
@dutow dutow merged commit 0586660 into percona:main Aug 28, 2024
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants