CPU usage has increased on batch_size of 800
Maintainers usually reply within 2 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- postgresql, sql
- Domain
- performance, testing
Research direction
The issue compares CPU usage at two commits and proposes CPU and time_taken thresholds, but names no benchmark files or test entry points. Start by locating the performance workflow behind the linked Actions runs and checking how it measures batch_size 800. Done means the workflow checks CPU and elapsed time against agreed thresholds so regressions are detected before merge.
Written by the indexing model from the issue text.
Description
Problem
-
At https://github.com/supabase/pg_net/commit/a19242c6d32e9bc934886103580b7b06a21c9daa, CPU usage was always lower than 10%: https://github.com/supabase/pg_net/actions/runs/35648621577#summary-106495141659
-
On master https://github.com/supabase/pg_net/commit/897cf5b7a032a87f7feedb82ee6755f5b4975c53, the CPU usage reaches 12%: https://github.com/supabase/pg_net/actions/runs/38368563453#summary-115199556419
I haven't bisected this to determine the cause.
Note that in the past, users have reported many tickets whenever pg_net uses too much CPU.
Solution
Ideally we should test a CPU and time_taken threshold so perf regressions are detected before merging.
- Dominant language
- Python
- Stars
- 376
- Forks
- 44
- Avg merge
- 5d 11h
- Merged PRs (30d)
- 16
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from supabase/pg_net
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
supabase/pg_net#235 · 1 comment ·
Maintainers usually reply within 2 days
-
idea
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
supabase/pg_net#159 · 1 reaction ·
Maintainers usually reply within 2 days
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
Maintainers usually reply within 2 days
-
Difficulty 3/5 1-2 days Newbie friendliness 72/100
Maintainers usually reply within 2 days
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
supabase/pg_net#320 · 1 reaction ·
Maintainers usually reply within 2 days
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
huggingface/smolagents#3106 ·
Maintainers usually reply within 2 days
-
area:scripts area:tests bug priority:later
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Ikalus1988/MisakaNet#4358 ·
Maintainers usually reply within 1 day
-
Discovered ports from service discovery are never propagated to modules in Module.load()Possibly taken @vishalmore90 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
OWASP/Nettacker#1828 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
aws-samples/sample-per-model-bedrock#708 ·
Maintainers usually reply within 1 day
-
maintenance
Difficulty 2/5 1-3 hours Newbie friendliness 62/100