Connection pooling can be done two places. Server side or client side,
though client side in reality may be a middle-tier layer, not an actual
application.
One possible pooling model is to have a bunch of worker connections opened
to the pgsql instance. Then as sql statements arrive the they are routed
through an available connection that is open but not doing any work. So 100
inbound connection may be "multiplexed" to 10 outbound connections to the
pgsql instance.
One issue is if a transaction is started with a BEGIN statement, or if the
isolation level is serializable or something. During the life time of a
transaction it is important not to multiplex otherwise statements appear to
be part of a transaction they don't belong to, or commits commit on a
different connection then a BEGIN was started on. Since pgsql defaults to an
autocommit model, most normal sql statements can be multiplexed willy-nilly,
but formally it more proper to say they are multiplexed on transaction
boundries (and there just happens to be a transaction commit behind most
statements).
Or something like that,
August
This assumes transactions are defined along the connection.
"Doug McNaught" <doug@wireboard.com> wrote in message
news:m31ymnlqaf.fsf@belphigor.mcnaught.org...
> "August Zajonc" <junk-pgsql@aontic.com> writes:
>
> > Curious if anyone has done any work on client side connection pooling
> > recently? I'm thinking pooling multiplexed against transaction commits?
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> What does this phrase mean exactly?
>
> -Doug
> --
> Free Dmitry Sklyarov!
> http://www.freesklyarov.org/
>
> We will return to our regularly scheduled signature shortly.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly