Documentation diff

[Marcos Pegoraro]

It's not easy to see what exactly changed between this and that version, on
a specific page on documentation. As an example I got this page but you'll
see this problem anywhere on docs.

https://www.postgresql.org/docs/16/functions-json.html
and
https://www.postgresql.org/docs/devel/functions-json.html

There are lots of new functions and better explanations of old features.
Then my question is, how to know all pages which were changed and what
exactly was changed on those pages ?

Regars
Marcos

Re: Documentation diff

[Daniel Gustafsson]

> On 25 Feb 2024, at 14:04, Marcos Pegoraro  wrote:

> There are lots of new functions and better explanations of old features. 
> Then my question is, how to know all pages which were changed and what 
> exactly was changed on those pages ?

Which problem are you trying to solve?  You should be reading the version of
the docs which corresponds to the version you are running.  If you are trying
to figure out an upgrade then the release notes are probably a better starting
point.

--
Daniel Gustafsson

Re: Documentation diff

[Marcos Pegoraro]

>
> Which problem are you trying to solve?  You should be reading the version
> of
> the docs which corresponds to the version you are running.  If you are
> trying
> to figure out an upgrade then the release notes are probably a better
> starting
> point.

Daniel Gustafsson
>

All the time we have doubts about what function exists in what version, or
was changed.
IS JSON belongs to 15 or 16, MERGE was done on 14 or 15, as example, are
completely new, so that feature will not run on previous versions.
But sometimes a function is changed a bit or a new easier function is
added, like [1].
Before all those new JSONPATH operators and methods were added, I could do
all those operations and return anything I wanted, but they are a lot
easier.

But if I don't read that page carefully, word by word, I will not see that
that function exists. And this needs to be done on all pages.
What changes were done on CREATE TABLE for version 16 ? Hmm, cool, STORAGE
can be defined at CREATE TABLE stage and not only at ALTER TABLE anymore.
But to know that I have to read that page carefully, do you understand me ?

So I was thinking of a way to get differences between this and that
versions, and for all doc pages.
Something like we already have on [2], it explicits, this feature was
introduced, this was changed, this does not exist anymore.

[1] -
https://www.postgresql.org/docs/devel/functions-json.html#FUNCTIONS-SQLJSON-PATH-OPERATORS
[2] - https://www.postgresql.org/about/featurematrix/

regards
Marcos

Re: Documentation diff

[Adrian Klaver]

On 2/25/24 08:38, Marcos Pegoraro wrote:

Which problem are you trying to solve?  You should be reading the
version of
the docs which corresponds to the version you are running.  If you
are trying
to figure out an upgrade then the release notes are probably a
better starting
point. 


Daniel Gustafsson


All the time we have doubts about what function exists in what version, 
or was changed.
IS JSON belongs to 15 or 16, MERGE was done on 14 or 15, as example, are 
completely new, so that feature will not run on previous versions.
But sometimes a function is changed a bit or a new easier function is 
added, like [1].
Before all those new JSONPATH operators and methods were added, I could 
do all those operations and return anything I wanted, but they are a lot 
easier.


But if I don't read that page carefully, word by word, I will not see 
that that function exists. And this needs to be done on all pages.
What changes were done on CREATE TABLE for version 16 ? Hmm, cool, 
STORAGE can be defined at CREATE TABLE stage and not only at ALTER TABLE 
anymore.

But to know that I have to read that page carefully, do you understand me ?

So I was thinking of a way to get differences between this and that 
versions, and for all doc pages.
Something like we already have on [2], it explicits, this feature was 
introduced, this was changed, this does not exist anymore.


Options:

1) One page release notes

https://bucardo.org/postgres_all_versions

Though you will get false positives on search for features that had 
fixes in minor releases.


2) Or just read the release notes for the initial release of each major 
version.





[1] - 
https://www.postgresql.org/docs/devel/functions-json.html#FUNCTIONS-SQLJSON-PATH-OPERATORS 
[2] - https://www.postgresql.org/about/featurematrix/ 



regards
Marcos


--
Adrian Klaver
adrian.kla...@aklaver.com

Re: Documentation diff

[Erik Wienhold]

On 2024-02-25 17:38 +0100, Marcos Pegoraro wrote:
> All the time we have doubts about what function exists in what version, or
> was changed.

pgPedia may give you some overview, although it does not claim to be
up-to-date.

> IS JSON belongs to 15 or 16, MERGE was done on 14 or 15, as example, are
> completely new, so that feature will not run on previous versions.

MERGE, for example: https://pgpedia.info/m/merge.html

> But if I don't read that page carefully, word by word, I will not see that
> that function exists. And this needs to be done on all pages.
> What changes were done on CREATE TABLE for version 16 ? Hmm, cool, STORAGE
> can be defined at CREATE TABLE stage and not only at ALTER TABLE anymore.
> But to know that I have to read that page carefully, do you understand me ?

CREATE TABLE: https://pgpedia.info/c/create-table.html

-- 
Erik

Re: Documentation diff

[Daniel Gustafsson]

> On 25 Feb 2024, at 17:38, Marcos Pegoraro  wrote:

> So I was thinking of a way to get differences between this and that versions, 
> and for all doc pages.
> Something like we already have on [2], it explicits, this feature was 
> introduced, this was changed, this does not exist anymore.

The documentation is written in heavily structured form using XML, you can most
likely write a diffing tool fairly easily which gives enough hints to know what
to read up on (or find an existing tool where plugging in a XPath expression
suffice).  By the sounds of it you are mostly interested in things found in
tables which makes it even easier.

--
Daniel Gustafsson

Local replication "slot does not exist" after initial sync

[Mike Lissner]

Hi, I set up logical replication a few days ago, but it's throwing some
weird log lines that have me worried. Does anybody have experience with
lines like the following on a subscriber:

LOG: logical replication table synchronization worker for subscription
"compass_subscription", table "search_opinionscitedbyrecapdocument" has
started
ERROR: could not start WAL streaming: ERROR: replication slot
"pg_20031_sync_17418_7324846428853951375" does not exist
LOG: background worker "logical replication worker" (PID 1014) exited with
exit code 1

Slots with this kind of name (pg_xyz_sync_*) are created during the initial
sync, but it seems like the subscription is working based on a quick look
in a few tables.

I thought this might be related to running out of slots on the publisher,
so I increased both max_replication_slots and max_wal_senders to 50 and
rebooted so those would take effect. No luck.

I thought rebooting the subscriber might help. No luck.

When I look in the publisher to see the slots we have...

SELECT * FROM pg_replication_slots;

...I do not see the one that's missing according to the log lines.

So it seems like the initial sync might have worked properly (tables have
content), but that I have an errant process on the subscriber that might be
stuck in a retry loop.

I haven't been able to fix this, and I think my last attempt might be a new
subscription with copy_data=false, but I'd rather avoid that if I can.

Is there a way to fix or understand this so that I don't get the log lines
forever and so that I can be confident the replication is in good shape?

Thank you!


Mike

Re: Local replication "slot does not exist" after initial sync

[Mike Lissner]

Sorry, two more little things here. The publisher logs add much, but here's
what we see:

STATEMENT: START_REPLICATION SLOT "pg_20031_sync_17418_7324846428853951375"
LOGICAL F1D0/346C6508 (proto_version '2', publication_names
'"compass_publication2"')
ERROR: replication slot "pg_20031_sync_17402_7324846428853951375" does not
exist

And I thought that maybe there'd be some magic in the REFRESH command on
the subscriber, so I tried that:

alter subscription xyz refresh publication;


To nobody's surprise, that didn't help. :)


On Sun, Feb 25, 2024 at 10:00 AM Mike Lissner <
mliss...@michaeljaylissner.com> wrote:

> Hi, I set up logical replication a few days ago, but it's throwing some
> weird log lines that have me worried. Does anybody have experience with
> lines like the following on a subscriber:
>
> LOG: logical replication table synchronization worker for subscription
> "compass_subscription", table "search_opinionscitedbyrecapdocument" has
> started
> ERROR: could not start WAL streaming: ERROR: replication slot
> "pg_20031_sync_17418_7324846428853951375" does not exist
> LOG: background worker "logical replication worker" (PID 1014) exited with
> exit code 1
>
> Slots with this kind of name (pg_xyz_sync_*) are created during the
> initial sync, but it seems like the subscription is working based on a
> quick look in a few tables.
>
> I thought this might be related to running out of slots on the publisher,
> so I increased both max_replication_slots and max_wal_senders to 50 and
> rebooted so those would take effect. No luck.
>
> I thought rebooting the subscriber might help. No luck.
>
> When I look in the publisher to see the slots we have...
>
> SELECT * FROM pg_replication_slots;
>
> ...I do not see the one that's missing according to the log lines.
>
> So it seems like the initial sync might have worked properly (tables have
> content), but that I have an errant process on the subscriber that might be
> stuck in a retry loop.
>
> I haven't been able to fix this, and I think my last attempt might be a
> new subscription with copy_data=false, but I'd rather avoid that if I can.
>
> Is there a way to fix or understand this so that I don't get the log lines
> forever and so that I can be confident the replication is in good shape?
>
> Thank you!
>
>
> Mike
>

Re: Local replication "slot does not exist" after initial sync

[Justin]

On Sun, Feb 25, 2024 at 1:11 PM Mike Lissner 
wrote:

> Sorry, two more little things here. The publisher logs add much, but
> here's what we see:
>
> STATEMENT: START_REPLICATION SLOT
> "pg_20031_sync_17418_7324846428853951375" LOGICAL F1D0/346C6508
> (proto_version '2', publication_names '"compass_publication2"')
> ERROR: replication slot "pg_20031_sync_17402_7324846428853951375" does not
> exist
>
> And I thought that maybe there'd be some magic in the REFRESH command on
> the subscriber, so I tried that:
>
> alter subscription xyz refresh publication;
>
>
> To nobody's surprise, that didn't help. :)
>
>
> On Sun, Feb 25, 2024 at 10:00 AM Mike Lissner <
> mliss...@michaeljaylissner.com> wrote:
>
>> Hi, I set up logical replication a few days ago, but it's throwing some
>> weird log lines that have me worried. Does anybody have experience with
>> lines like the following on a subscriber:
>>
>> LOG: logical replication table synchronization worker for subscription
>> "compass_subscription", table "search_opinionscitedbyrecapdocument" has
>> started
>> ERROR: could not start WAL streaming: ERROR: replication slot
>> "pg_20031_sync_17418_7324846428853951375" does not exist
>> LOG: background worker "logical replication worker" (PID 1014) exited
>> with exit code 1
>>
>> Slots with this kind of name (pg_xyz_sync_*) are created during the
>> initial sync, but it seems like the subscription is working based on a
>> quick look in a few tables.
>>
>> I thought this might be related to running out of slots on the publisher,
>> so I increased both max_replication_slots and max_wal_senders to 50 and
>> rebooted so those would take effect. No luck.
>>
>> I thought rebooting the subscriber might help. No luck.
>>
>> When I look in the publisher to see the slots we have...
>>
>> SELECT * FROM pg_replication_slots;
>>
>> ...I do not see the one that's missing according to the log lines.
>>
>> So it seems like the initial sync might have worked properly (tables have
>> content), but that I have an errant process on the subscriber that might be
>> stuck in a retry loop.
>>
>> I haven't been able to fix this, and I think my last attempt might be a
>> new subscription with copy_data=false, but I'd rather avoid that if I can.
>>
>> Is there a way to fix or understand this so that I don't get the log
>> lines forever and so that I can be confident the replication is in good
>> shape?
>>
>> Thank you!
>>
>>
>> Mike
>>
>
Hi Mike
This happens when there is an error with another sync worker,  PG has
issues when this happens, the Logical Replication Main Worker  attempts to
sync another table, creates a slots, then tries to sync that table,  then
errors out as it is out of sync workers,  then attempts to sync another
table. the Subscriber is then stuck in a loop  using up all the slots on
the publisher,.  The subscriber continues to cycle through all the tables
that are not status r in the pg_subscription_rel table.  Once there no
slots available on the publisher the subscriber attempts to create slots,
fails and returns the above errors.

These are not critical errors however it is difficult to clean   up as
every time starting and stopping the subscriber it immediately retries to
initial sync the tables it has slots for.  So it keeps using  up all the
publisher slots.

You need to look through the logs looking for the initial error that kicked
this off,  it can be a duplicate key or the subscriber or publisher
disconnected due to wal_reciever_timeout or wal_sender_timerout.

I typical disable all the timeouts as it does not take much to cause the
subscriber and publisher to think the connection has timed out.

A tell tale sign of this is the pg_subscription_rel status will be d for a
bunch of tables.  There should only be few tables that are status d,

I only attempt to clean this up when working on big databases and a lot of
tables have already been sync.

Need to figure out the initial cause of the problem, correct that error and
attempt an initial sync again.

  .

Re: Documentation diff

[jian he]

On Mon, Feb 26, 2024 at 1:49 AM Daniel Gustafsson  wrote:
>
> > On 25 Feb 2024, at 17:38, Marcos Pegoraro  wrote:
>
> > So I was thinking of a way to get differences between this and that 
> > versions, and for all doc pages.
> > Something like we already have on [2], it explicits, this feature was 
> > introduced, this was changed, this does not exist anymore.
>
> The documentation is written in heavily structured form using XML, you can 
> most
> likely write a diffing tool fairly easily which gives enough hints to know 
> what
> to read up on (or find an existing tool where plugging in a XPath expression
> suffice).  By the sounds of it you are mostly interested in things found in
> tables which makes it even easier.
>
> --
> Daniel Gustafsson
>
>
>

I just found out this:
https://demo.deltaxml.com/compare-demonstration-results-sample/

but I guess the OP wants a side by side rendered html comparison.
like you buy a iphone then you can compare it like this:
https://www.apple.com/iphone/compare/

Fastest way to clone schema ~1000x

[Emiel Mols]

Hello,

To improve our unit and end-to-end testing performance, we are looking to
optimize initialization of around 500-1000 database *schemas* from a
schema.sql file.

Background: in postgres, you cannot change databases on
existing connections, and using schemas would allow us to minimize the
amount of active connections needed from our test runners, as we can reuse
connections by updating search_path. In our current database-per-test setup
we see that there is around a ~30% (!!) total CPU overhead in
native_queued_spin_lock_slowpath (as profiled with linux perf), presumably
because of the high connection count. We run ~200 tests in parallel to
saturate a 128 core machine.

In the schema-per-test setup, however, it becomes harder to cheaply create
the schema. Before we could `create database test001 with template
testbase` to set up the database for a test, and this was reasonably fast.
Re-inserting a schema with ~500 table/index definitions across 500 test
schema's is prohibitively expensive (around 1000ms per schema insertion
means we're wasting 500 cpu-seconds, and there seems to be quite some lock
contention too). Linux perf shows that in this setup we're reducing the
native_queued_spin_lock_slowpath overhead to around 10%, but total test
time is still slower due to all schema initialization being done. Also it
feels quite elegant functions and types can be reused between tests.

Does anyone have some insights or great ideas :)? Also pretty curious to
the fundamental reason why having high/changing connection counts to
postgres results in this much (spin)lock contention (or perhaps we're doing
something wrong in either our configuration or measurements?).

An alternative we haven't explored yet is to see if we can use pgbouncer or
other connection pooler to mitigate the 30% issue (set limits so there are
only ever X connections to postgres in total, and perhaps max Y per
test/database). This does add another piece of infrastructure/complexity,
so not really prefered.

Best,

Emiel

Re: Fastest way to clone schema ~1000x

[Pavel Stehule]

Hi

po 26. 2. 2024 v 7:28 odesílatel Emiel Mols  napsal:

> Hello,
>
> To improve our unit and end-to-end testing performance, we are looking to
> optimize initialization of around 500-1000 database *schemas* from a
> schema.sql file.
>
> Background: in postgres, you cannot change databases on
> existing connections, and using schemas would allow us to minimize the
> amount of active connections needed from our test runners, as we can reuse
> connections by updating search_path. In our current database-per-test setup
> we see that there is around a ~30% (!!) total CPU overhead in
> native_queued_spin_lock_slowpath (as profiled with linux perf), presumably
> because of the high connection count. We run ~200 tests in parallel to
> saturate a 128 core machine.
>
> In the schema-per-test setup, however, it becomes harder to cheaply create
> the schema. Before we could `create database test001 with template
> testbase` to set up the database for a test, and this was reasonably fast.
> Re-inserting a schema with ~500 table/index definitions across 500 test
> schema's is prohibitively expensive (around 1000ms per schema insertion
> means we're wasting 500 cpu-seconds, and there seems to be quite some lock
> contention too). Linux perf shows that in this setup we're reducing the
> native_queued_spin_lock_slowpath overhead to around 10%, but total test
> time is still slower due to all schema initialization being done. Also it
> feels quite elegant functions and types can be reused between tests.
>
> Does anyone have some insights or great ideas :)? Also pretty curious to
> the fundamental reason why having high/changing connection counts to
> postgres results in this much (spin)lock contention (or perhaps we're doing
> something wrong in either our configuration or measurements?).
>
> An alternative we haven't explored yet is to see if we can use pgbouncer
> or other connection pooler to mitigate the 30% issue (set limits so there
> are only ever X connections to postgres in total, and perhaps max Y per
> test/database). This does add another piece of infrastructure/complexity,
> so not really prefered.
>

For testing

a) use templates - CREATE DATABASE test TEMPLATE some;

b) disable fsync (only for testing!!!)

Regards

Pavel


> Best,
>
> Emiel
>

Re: Creating table and indexes for new application

[Lok P]

On Sun, 25 Feb, 2024, 1:05 am yudhi s,  wrote:

>
> On Fri, Feb 23, 2024 at 5:26 PM sud  wrote:
>
>>
>>
>> On Fri, 23 Feb, 2024, 1:28 pm yudhi s, 
>> wrote:
>>
>>>
>>>
>>> On Fri, 23 Feb, 2024, 1:20 pm sud,  wrote:
>>>


 On Fri, 23 Feb, 2024, 12:41 pm Laurenz Albe, 
 wrote:

> On Fri, 2024-02-23 at 02:05 +0530, yudhi s
>
> > 2)Should we be creating composite indexes on each foreign key for
> table2 and table3, because
> >   any update or delete on parent is going to take lock on all child
> tables?
>
> Every foreign key needs its own index.  A composite index is only
> appropriate if the foreign
> key spans multiple columns.
>
>

 From the DDL which OP posted it's using composite foreign key thus a
 composite index would be needed.
 However, if someone doesn't delete or update the parent table PK   , is
 it still advisable to have all the FK indexed? Like in general I think
 transaction id should not get updated in a normal scenario unless some
 special case.



>>> Thank you. I can double check if we have confirmed use case of deleting
>>> the parent table or updating PK in the parent table. But anyway it can
>>> happen for data fix for sure in some scenario.
>>>
>>> But yes, we are certainly going to drop/purge partition from all the
>>> parent and child table after specific days. So isn't that need the FK to be
>>> indexed or else it will scan whole parent table partition?
>>>
>>
>>
>> I am not sure if drop partition of parent table, will have a lock or will
>> do a full scan on the child table while doing the partition maintenance or
>> dropping the partitions, in absence of foreign key index. Others may
>> comment here.
>>
>>>

> Can you please help me understand, If it's true that all the statements
> like Delete, Update and Drop partition of parent table will take lock on
> the child table and Full scan the child table , and thus foreign key index
> on all the child table is necessary irrespective of the performance
> overhead it has on all the INSERT queries into the child tables?
>


Not sure of the lock but I think you should be able to see a full scan on
child table while doing delete or update of parent table PK. Explain
Analyze should show that I believe. Not sure if explain analyze will work
for drop partition too.

>

Re: Fastest way to clone schema ~1000x

[Emiel Mols]

Thanks, as indicated we're using that right now. The 30% spinlock overhead
unfortunately persists.

- Fsync was already disabled, too. Complete postgresql.conf used in testing:
listen_addresses = ''
max_connections = 2048
unix_socket_directories = '..'
shared_buffers = 128MB
log_line_prefix = ''
synchronous_commit = 'off'
wal_level = 'minimal'

- linux perf report comparing schema-per-test vs database-per-test:
https://ibb.co/CW5w2MW

- Emiel


On Mon, Feb 26, 2024 at 1:36 PM Pavel Stehule 
wrote:

> Hi
>
> po 26. 2. 2024 v 7:28 odesílatel Emiel Mols  napsal:
>
>> Hello,
>>
>> To improve our unit and end-to-end testing performance, we are looking to
>> optimize initialization of around 500-1000 database *schemas* from a
>> schema.sql file.
>>
>> Background: in postgres, you cannot change databases on
>> existing connections, and using schemas would allow us to minimize the
>> amount of active connections needed from our test runners, as we can reuse
>> connections by updating search_path. In our current database-per-test setup
>> we see that there is around a ~30% (!!) total CPU overhead in
>> native_queued_spin_lock_slowpath (as profiled with linux perf), presumably
>> because of the high connection count. We run ~200 tests in parallel to
>> saturate a 128 core machine.
>>
>> In the schema-per-test setup, however, it becomes harder to cheaply
>> create the schema. Before we could `create database test001 with template
>> testbase` to set up the database for a test, and this was reasonably fast.
>> Re-inserting a schema with ~500 table/index definitions across 500 test
>> schema's is prohibitively expensive (around 1000ms per schema insertion
>> means we're wasting 500 cpu-seconds, and there seems to be quite some lock
>> contention too). Linux perf shows that in this setup we're reducing the
>> native_queued_spin_lock_slowpath overhead to around 10%, but total test
>> time is still slower due to all schema initialization being done. Also it
>> feels quite elegant functions and types can be reused between tests.
>>
>> Does anyone have some insights or great ideas :)? Also pretty curious to
>> the fundamental reason why having high/changing connection counts to
>> postgres results in this much (spin)lock contention (or perhaps we're doing
>> something wrong in either our configuration or measurements?).
>>
>> An alternative we haven't explored yet is to see if we can use pgbouncer
>> or other connection pooler to mitigate the 30% issue (set limits so there
>> are only ever X connections to postgres in total, and perhaps max Y per
>> test/database). This does add another piece of infrastructure/complexity,
>> so not really prefered.
>>
>
> For testing
>
> a) use templates - CREATE DATABASE test TEMPLATE some;
>
> b) disable fsync (only for testing!!!)
>
> Regards
>
> Pavel
>
>
>> Best,
>>
>> Emiel
>>
>

Re: Fastest way to clone schema ~1000x

[Pavel Stehule]

po 26. 2. 2024 v 8:08 odesílatel Emiel Mols  napsal:

> Thanks, as indicated we're using that right now. The 30% spinlock overhead
> unfortunately persists.
>

try to increase shared_buffer

128MB can be too low

max_connection = 2048 - it unrealistic high


> - Fsync was already disabled, too. Complete postgresql.conf used in
> testing:
> listen_addresses = ''
> max_connections = 2048
> unix_socket_directories = '..'
> shared_buffers = 128MB
> log_line_prefix = ''
> synchronous_commit = 'off'
> wal_level = 'minimal'
>
> - linux perf report comparing schema-per-test vs database-per-test:
> https://ibb.co/CW5w2MW
>
> - Emiel
>
>
> On Mon, Feb 26, 2024 at 1:36 PM Pavel Stehule 
> wrote:
>
>> Hi
>>
>> po 26. 2. 2024 v 7:28 odesílatel Emiel Mols  napsal:
>>
>>> Hello,
>>>
>>> To improve our unit and end-to-end testing performance, we are looking
>>> to optimize initialization of around 500-1000 database *schemas* from a
>>> schema.sql file.
>>>
>>> Background: in postgres, you cannot change databases on
>>> existing connections, and using schemas would allow us to minimize the
>>> amount of active connections needed from our test runners, as we can reuse
>>> connections by updating search_path. In our current database-per-test setup
>>> we see that there is around a ~30% (!!) total CPU overhead in
>>> native_queued_spin_lock_slowpath (as profiled with linux perf), presumably
>>> because of the high connection count. We run ~200 tests in parallel to
>>> saturate a 128 core machine.
>>>
>>> In the schema-per-test setup, however, it becomes harder to cheaply
>>> create the schema. Before we could `create database test001 with template
>>> testbase` to set up the database for a test, and this was reasonably fast.
>>> Re-inserting a schema with ~500 table/index definitions across 500 test
>>> schema's is prohibitively expensive (around 1000ms per schema insertion
>>> means we're wasting 500 cpu-seconds, and there seems to be quite some lock
>>> contention too). Linux perf shows that in this setup we're reducing the
>>> native_queued_spin_lock_slowpath overhead to around 10%, but total test
>>> time is still slower due to all schema initialization being done. Also it
>>> feels quite elegant functions and types can be reused between tests.
>>>
>>> Does anyone have some insights or great ideas :)? Also pretty curious to
>>> the fundamental reason why having high/changing connection counts to
>>> postgres results in this much (spin)lock contention (or perhaps we're doing
>>> something wrong in either our configuration or measurements?).
>>>
>>> An alternative we haven't explored yet is to see if we can use pgbouncer
>>> or other connection pooler to mitigate the 30% issue (set limits so there
>>> are only ever X connections to postgres in total, and perhaps max Y per
>>> test/database). This does add another piece of infrastructure/complexity,
>>> so not really prefered.
>>>
>>
>> For testing
>>
>> a) use templates - CREATE DATABASE test TEMPLATE some;
>>
>> b) disable fsync (only for testing!!!)
>>
>> Regards
>>
>> Pavel
>>
>>
>>> Best,
>>>
>>> Emiel
>>>
>>