starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Use Postgres' COPY protocol when reserving IPs in a prefix #4699

New Issue
Closed
opened 2025-12-29 19:19:37 +01:00 by adam · 1 comment
adam commented 2025-12-29 19:19:37 +01:00
Owner
Copy Link

Originally created by @jeromer on GitHub (Mar 25, 2021).

NetBox version

v2.8.7

Feature type

Change to existing functionality

Proposed functionality

If I'm not mistaken (I'm far from being a Django expert) in PrefixViewSet.available_ips Netbox will loop over requested IPs and INSERT them one by one. The idea is to use the Postgres COPY protocol so all IP addresses are added in one go. Obviously this will only benefit for Postgres users.

Use case

While this is functional, this becomes slow when a user wants to reserve for example 15 IPs in a given prefix as Postgres will trigger some internal machinery (index updates for example) for each INSERT. So the more INSERT the slower. Which means an increasing risk of lock contention as the Postgres advisory lock will be released only after all the DB operations (INSERTs and subsequent SELECT for the output serializer) are executed which increases the risk of lock contention proportionally to the amount of IP which need to be reserved.

Using the COPY protocol would help making the creation phase much faster, thus reducing lock contention.

Database changes

No schema changes are required

External dependencies

No new dependency is required.

Originally created by @jeromer on GitHub (Mar 25, 2021). ### NetBox version v2.8.7 ### Feature type Change to existing functionality ### Proposed functionality If I'm not mistaken (I'm far from being a Django expert) in [PrefixViewSet.available_ips](https://github.com/netbox-community/netbox/blob/master/netbox/ipam/api/views.py#L191) Netbox will loop over requested IPs and `INSERT` them one by one. The idea is to use the Postgres [COPY](https://www.postgresql.org/docs/current/sql-copy.html) protocol so all IP addresses are added in one go. Obviously this will only benefit for Postgres users. ### Use case While this is functional, this becomes slow when a user wants to reserve for example 15 IPs in a given prefix as Postgres will trigger some internal machinery (index updates for example) for each `INSERT`. So the more `INSERT` the slower. Which means an increasing risk of lock contention as the Postgres advisory lock will be released only after all the DB operations (`INSERT`s and subsequent `SELECT` for the output serializer) are executed which increases the risk of lock contention proportionally to the amount of IP which need to be reserved. Using the `COPY` protocol would help making the creation phase much faster, thus reducing lock contention. ### Database changes No schema changes are required ### External dependencies No new dependency is required.
adam added the type: feature label 2025-12-29 19:19:37 +01:00
adam closed this issue 2025-12-29 19:19:37 +01:00
adam commented 2025-12-29 19:19:38 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 21, 2021):

Creating each instance individually is necessary to ensure both the enforcement of assigned permissions and the creation of the necessary change records. It's a nice idea for optimization, but these are critical functions.

@jeremystretch commented on GitHub (Apr 21, 2021): Creating each instance individually is necessary to ensure both the enforcement of assigned permissions and the creation of the necessary change records. It's a nice idea for optimization, but these are critical functions.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#4699
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?