Thread: Re: Database creation performance drop going from pg 14 to pg 15+

Re: Database creation performance drop going from pg 14 to pg 15+

From
"Mahdi Bahrami"
Date:
I had some more time/mood to mess around with this. Interestingly enough, psql CLI seems to be consistently slower than the Swift client (PostgresNIO: https://github.com/vapor/postgres-nio) that I was using. The new psql-CLI packet captures are attached.

Though it does appear that psql uses SimpleQuery by default, which makes sense considering it's a CLI tool. PostgresNIO uses ExtendedQuery by default which can explain the differences. PostgresNIO does not support SimpleQuery yet; I'm awaiting a review for a PR that adds that support: https://github.com/vapor/postgres-nio/pull/505.

The other notable thing is that I re-ran the scripts but with using psql CLI, and although things are slower (per the packet captures), they are at least consistent. I can't see any significant performance differences between Postgres versions when using psql CLI, which might mean that this performance degradation only happens under ExtendedQuery and not SimpleQuery.

Here's how I ran the commands that seem to be at fault when using PostgresNIO. I only ran the drop-db create-db commands, not the whole chain, which should still be sufficient:
```
PGPASSWORD=xxx psql -U spi_test -h 127.0.0.1 postgres -c "DROP DATABASE IF EXISTS spi_test WITH (FORCE);" -c "CREATE DATABASE spi_test;"
```

For checking this against multiple postgres versions and different auth mechanisms like in the original repo in the `run-perf-test.sh` script, I ran the commands through Docker CLI (podman to be precise, docker is an alias to podman here):
```
docker exec spi_test bash -c 'COMMAND_ABOVE'
```

For packet captures, I opened up a shell into the container and ran the psql command while having tcpdump capturing the packets.

Here's an image of an overview of the packet captures. The 2 on the left are the old ones with PostgresNIO, the 2 on the right are the new ones using psql. The postgres versions are mentioned in the Wireshark window names up there or down below.



As you can see in the image, the psql ones consistently take 63ms compared to the 37/51ms of when using PostgresNIO.
The StartupMessage is set as the time reference for all captures.
For clarity, in the image only the first connection is filtered-in from the PostgresNIO captures.
Attachment

Re: Database creation performance drop going from pg 14 to pg 15+

From
Álvaro Herrera
Date:
On 2025-May-27, Mahdi Bahrami wrote:

> Here's how I ran the commands that seem to be at fault when using
> PostgresNIO. I only ran the drop-db create-db commands, not the whole
> chain, which should still be sufficient:
> ```
> PGPASSWORD=xxx psql -U spi_test -h 127.0.0.1 postgres -c "DROP DATABASE IF EXISTS spi_test WITH (FORCE);" -c "CREATE
DATABASEspi_test;"
 
> ```

I wonder if this is related to the change to CREATE DATABASE in release 15.
Maybe you could test this with "CREATE DATABASE spi_test STRATEGY =
file_copy;" and see if that returns it to the original performance.
The new strategy is allegedly faster, but maybe in your case, for
whatever reason, it isn't.

I do wonder why is the database drop/create performance so critical,
though.  I mean, surely there are more relevant performance problems to
be concerned about.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"Tiene valor aquel que admite que es un cobarde" (Fernandel)



Re: Database creation performance drop going from pg 14 to pg 15+

From
"Mahdi Bahrami"
Date:
To be clear the "15s instead of 1m30s" was related to another issue about SASL implementation of PostgresNIO being slow, not this CREATE DATABASE strategy change. I was just trying to explain that in their set up, these saved milliseconds do matter for whatever reason.

Re: Database creation performance drop going from pg 14 to pg 15+

From
"Mahdi Bahrami"
Date:
Here's what the OP of the PostgresNIO issue has mentioned about what performance impact usage of `file_copy` has in his setup (https://github.com/SwiftPackageIndex/SwiftPackageIndex-Server/pull/3812):

Series: Default Strategy
Suite AllTests passed after 5.081 seconds
Suite AllTests passed after 5.274 seconds
Suite AllTests passed after 5.306 seconds
Suite AllTests passed after 5.224 seconds
Suite AllTests passed after 6.343 seconds
Suite AllTests passed after 5.450 seconds
Series: file_copy Strategy
Suite AllTests passed after 4.729 seconds
Suite AllTests passed after 4.755 seconds
Suite AllTests passed after 4.739 seconds
Suite AllTests passed after 4.772 seconds
Suite AllTests passed after 4.866 seconds
Suite AllTests passed after 4.855 seconds

This is them running the tests in parallel multiple times with and without file_copy, just to benchmark.
Overall ~0.5-6s / ~10% speedup, which isn't too significant at this level, but is still a noticeable relative improvement.