From: | Emiel Mols <emiel(at)crisp(dot)nl> |
---|---|
To: | daniel(at)yesql(dot)se |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Fastest way to clone schema ~1000x |
Date: | 2024-02-26 09:06:31 |
Message-ID: | CAF5w505X-OVN_EW9nsOYjBPLQ1auAdcDLKzreCeY5TO_YJEAtA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Feb 26, 2024 at 3:50 PM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> There is a measurable overhead in connections, regardless of if they are
> used
> or not. If you are looking to squeeze out performance then doing more over
> already established connections, and reducing max_connections, is a good
> place
> to start.
>
Clear, but with database-per-test (and our backend setup), it would have
been *great* if we could have switched database on the same connection
(similar to "USE xxx" in mysql). That would limit the connections to the
amount of workers, not multiplied by tests.
Even with a pooler, we're still going to be maintaining 1000s of
connections from the backend workers to the pooler. I would expect this to
be rather efficient, but still unnecessary. Also, both pgbouncer/pgpool
don't seem to support switching database in-connection (they could have
implemented the aforementioned "USE" statement I think!). [Additionally
we're using PHP that doesn't seem to have a good shared memory pool
implementation -- pg_pconnect is pretty buggy].
I'll continue with some more testing. Thanks for now!
From | Date | Subject | |
---|---|---|---|
Next Message | veem v | 2024-02-26 09:56:29 | Re: Performance issue debugging |
Previous Message | Daniel Gustafsson | 2024-02-26 08:50:37 | Re: Fastest way to clone schema ~1000x |