Looking at the gate jobs, the postgresql job is always slower than the mysql jobs (a couple of minutes). I don't think PosgreSQL needs to be slower than mysql, maybe there's a setup issue with how the database is setup?
Acceptance Criteria:
| Subject | Author | Repo | Branch | Lines +/- | |
|---|---|---|---|---|---|
| postgres: Use --db-dir for data directory via TMPDIR | Phedenskog | integration/quibble | master | +8 -2 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Peter | T422104 Decrease gate pipeline times | |||
| Resolved | Peter | T422110 Investigate quibble-for-mediawiki-core-vendor-postgres-php83 slowness |
Discussed this with @hashar and the slowness is probably because that PostgeSQL do not use tmpfs/memory. Lets invest some time and see if can configure it to use that.
Change #1268444 had a related patch set uploaded (by Phedenskog; author: Phedenskog):
[integration/quibble@master] postgres: Use --db-dir for data directory via TMPDIR
Change #1268444 merged by jenkins-bot:
[integration/quibble@master] postgres: Use --db-dir for data directory via TMPDIR
Mentioned in SAL (#wikimedia-releng) [2026-04-10T10:22:23Z] <hashar> Updated PostgreSQL jobs to Quibble 1.17.1 # T422110
We did a rebuild of quibble-for-mediawiki-core-vendor-postgres-php83 with Quibble 1.17.1 which completed in 14m 09s.
The job duration metrics can be seen at https://grafana.wikimedia.org/d/ccaceff0-9ca6-4c89-9c4b-9138003439bf/zuul-job-prometheus?orgId=1&from=now-7d&to=now&timezone=utc&var-pipeline=$__all&var-job=quibble-for-mediawiki-core-vendor-postgres-php83&var-status=SUCCESS&viewPanel=panel-5 Beware the Hourly, Daily, Weekly are lagging since they are the average of past builds duration over the selected period.
We will see after a few more builds happen, probably at some point next week.
Feel free to mark the task resolved (and kudos for the patch!)
I don't think this worked, it should have been faster (10-12 minutes):
I will try it out on a another machine next week to see better if the patch was correct or not.
Or it could be maybe some other configuration thing for PostgreSQL that could be fixed. Let me look next week.
The tmpfs patch made the test pass 2 minutes faster. I've been trying different performance settings (T423023#11829349) for Postgres but no change in performance. We are running an old version in CI (we should upgrade to 17 or 18) but the test speed will not improve (according to my tests). However when we run the tests in parallel T422108 that will increase the speed between 2.5-3 times.
I did some test test runs on an instance (8 CPU, 16GB RAM). All runs use --tmpfs /tmp:exec,size=4g (databases in memory),
QUIBBLE_PHPUNIT_PARALLEL=1, and --skip selenium,composer-test,npm-test,phpunit-standalone,api-testing,phpbench,qunit where I compared different Postgres version and running the PHP database tests in core serial vs in parallel:
Postgres 13 (PHP 8.3, 3 iterations)
| Run | Serial (s | Parallel (s) |
| r1 | 1010 | 294 |
| r2 | 993 | 282 |
| r3 | 1004 | 273 |
| Mean (r2-r3) | 999 | 278 |
| Speedup | 3.6x | |
Postgres 17 (PHP 8.3, 3 iterations)
| Run | Serial (s) | Parallel (s) |
| r1 | 998 (cold) | 281 |
| r2 | 1007 | 263 |
| r3 | 999 | 297 |
| Mean (r2-r3) | 1003 | 280 |
| Speedup | 3.6x | |
Postgres 18 (PHP 8.3, 3 iterations)
| Run | Serial (s) | Parallel (s) |
| r1 | 1031 (cold | 312 |
| r2 | 993 | 309 |
| r3 | 1007 | 293 |
| Mean (r2-r3) | 1000 | 301 |
| Speedup | 3.3x | |
There's no win in different version. Running the tests in parallel is the big win.