PostgreSQL backend: a waste of time?

[Nicola Ranaldo]

>I really don't know... This buffer is in the daemon?

This would be in the client.

>Don't you have to receive responses from the SQL DB? Or these commands
>are only writes (UPDATE, INSERT)? If these are only writes it seams a
>good ideia, but if you need to SELECT (inside the transaction) too there
>is the problem of different connections getting different transactions.

We can exec SELECT(s) immediately and store the other commands, i think this
would be safe, cyrus transactions are small and closed in a very local
context, for example: a create mailbox require an insert and some filesystem
operations, if these fail abort the transaction (this is also an example
showing that backends have to support transactions, in this case an
autocommit backend will leave a gangling mailbox!)

>It depends on you user base:
>If your system is a backend for a webmail, for instance, your "users"
>(the php or perl script) will always connect, fetch something,
>disconnect. In this situation you'll never see lots of simultaneous
>connections.

This is my case!

>If you have 50.000 users on a campus setup using IMAP you'll get 5000
>concurrent connection easily.

I do not know if PostgreSQL may scale up to these numbers! we need someone
experienced in this.

Another solution may be to open a connection only when you need it and close
it asap.


Regards

    Nicola Ranaldo