| From: | Ashesh Vashi <ashesh(dot)vashi(at)enterprisedb(dot)com> |
|---|---|
| To: | Hari Prasad <webdev(dot)byhari(at)gmail(dot)com> |
| Cc: | pgadmin-hackers(at)postgresql(dot)org |
| Subject: | Re: [pgAdmin] Startup speed improvements + identified bottlenecks (related to issue #9770) |
| Date: | 2026-03-23 05:32:53 |
| Message-ID: | CAG7mmoyTWSxzgqL0yChOMnjynfy75GSO0iCe0iJrHKmEqx9yAA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgadmin-hackers |
Hi Hari,
Thanks for showing interest in the development of pgAdmin4.
On Sun, Mar 22, 2026 at 12:22 AM Hari Prasad <webdev(dot)byhari(at)gmail(dot)com>
wrote:
> Hi,
>
> I have been looking into *pgAdmin desktop startup performance and
> identified multiple bottlenecks in the startup path. *A quick summary:
>
> - Synchronous DB migrations blocking startup
> - Redundant table validation on every launch
> - Eager loading of all modules/blueprints
>
- Driver/auth registries loaded upfront
>
- 1s polling delay in backend readiness detection
> - Sync logging during startup
>
> As a first step, I have implemented a small fix for the polling issue
> (adaptive polling instead of fixed 1000ms), which improves responsiveness
> without touching backend logic. *Also, the startup feels noticeably
> slower *than expected due to the amount of synchronous work being done
> upfront, which is what led me to dig into this.
>
Sounds good to me.
-- Ashesh
>
> *Before opening a PR *for this change, I wanted to check if this approach
> is acceptable.
>
> This is *part of ongoing work around issue #9770
> <https://github.com/pgadmin-org/pgadmin4/issues/9770>, *and I plan to
> address the other bottlenecks incrementally.
>
> Thanks and regards
> Hari
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hari Prasad | 2026-03-23 14:18:10 | Re: [pgAdmin] Startup speed improvements + identified bottlenecks (related to issue #9770) |
| Previous Message | Hari Prasad | 2026-03-21 18:52:35 | [pgAdmin] Startup speed improvements + identified bottlenecks (related to issue #9770) |