Re: [GENERAL] PgPool or alternatives

Hi

Thanks for the reply. We were not planning to use pgPools connection
pool mode, but its replication mode.

Our tests with pgPool allow us to install a backup db via pgPool to each
node, and tests loads overnight of 10+GB of inserts/updates/deletes all
work fine, with only a slight loss of performance vs a standalone DB.

I was wondering if there is another option that will allow me to spool
all ALTER|CREATE|DELETE|DROP|INSERT|UPDATE commands to all nodes, and
SELECTs to any of the connected nodes. The apllication can actually
handle separate READ|WRITE nodes from how it was written for Oracle.

Simon

On 21/01/2017 20:09, Stephen Frost wrote:
> Simon,
>
> * Simon Windsor (simon.windsor@cornfield.me.uk) wrote:
>> My employer wants to move from an in house Oracle solution to a
>> cloud based Postgres system. The system will involve a number of
>> data loaders running 24x7 feeding several Postgres Databases that
>> will be used by internal applications and external customer
>> applications.
>>
>> For the record, internal and external applications make heavy use of
>> Temporary tables, that are session related. This requirement means I
>> cannot consider normal replication methods.
>>
>> Is PgPool the only viable that will allow the system the data
>> loaders to feed [n] databases that will be functional identical?
> I'm not sure what you mean by 'functional identical', but I wouldn't
> generally consider that to be a property of pgpool (or pgbouncer, or any
> other connection pooler, really).
>
> That said, my general feeling is that pgbouncer tends to be simpler,
> faster, and less likely to introduce oddities that you don't expect.
> The 'session' mode might work for you, though it might be debatable if
> that really helps you all that much.  'transaction' mode is what I
> usually recommend as it allows idle connections to be handled by
> pgbouncer (unlike 'session' mode), but there are caveats to using that
> mode, of course.
>
> I'm a bit curious where you're thinking of using the connection pooler
> also though.  If you have data loaders running 24x7 feeding data
> constantly to PG, do you really need a connection pooler for those?
> Connection poolers make a lot of sense for environments where there's
> lots of down-time on the connection, but the less down-time, the less
> they make sense.
>
> Thanks!
>
> Stephen

--
Simon Windsor

Eml: simon.windsor@cornfield.me.uk
Tel: 01454 617689
Mob: 0755 197 9733


“There is nothing in the world that some man cannot make a little worse and sell a little cheaper, and he who considers
priceonly is that man's lawful prey.”