On 3/31/2016 17:47, Alvaro Herrera wrote: > Andrew Dunstan wrote: > >> On 03/31/2016 03:12 PM, Igor Neyman wrote: >>>> We are going to build system based on PostgreSQL database for huge >>>> number of individual users (few thousands). Each user will have his own >>>> account, for authorization we will use Kerberos (MIT or Windows). >>>> Most of users will have low activity, but for various reasons, connection >>>> should be open all the time. >>>> I'd like to know what potential problems and limitations we can expect >>>> with such deployment. >>>> During preliminary testing we have found that for each connection we >>>> need ~1MB RAM. Is there any way to decrease this ? Is there any risk, that >>>> such number of users will degrade performance ? >>>> I'll be happy to hear any remarks and suggestions related to design, >>>> administration and handling of such installation. >>> Take a look at PgBouncer. >>> It should solve your problems. >> If they are going to keep the client connections open, they would need to >> run pgbouncer in statement or transaction mode. > As I understand, in pgbouncer you cannot have connections that serve > different users. If each individual requires its own database-level > user, pgbouncer would not help at all. > > I would look seriously into getting rid of the always-open requirement > for connections. I'm trying to figure out where the "always open" requirement comes from; there are very, very few instances where that's real, when you get down to it.
-- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature