Wojtek Mach wrote:
Hi all,

I've read everything in this subject you guys has discussed already (including topic started by Max Zorloff) but I haven't found my answer yet.

I'm looking for hints on best configuration for my specific needs: I'm having complied program written in C, which reads lots of data from cellular network. Then my C code is running some complex transformations and finally inserts/updates data in main partitioned Postgres table and few standard tables. In production, the data will be coming all the time, around 30.000inserts/minute. Then, I have set of WebServices, which are invoked by limited number of customers (3-6 different logins) and runs some selects/DMLs against my database, no more then ~50queries/minute. Now, the question is: how my C code should connect to Postgres? You've recommended pgpool and pgbouncer, but I believe these connection poolers are rather to be used for webpages, where there is a lot of querying from different users. Am I wrong? Now I'm using pgconnect (yes, I've read it's "broke" but is working fine for me .).. Do you see reasons why I, in this setup, should move to any of connection poolers? Or there is a better way? The second question is should I go for connection poolers for my WebServices as well? If so, what are the reasons?

 From configuration POV, I'm using Apache, PHP and Postgres 8.2 server.
Final hardware setup is yet to be decided.

Will appreciate all the good comments.



BR,
[EMAIL PROTECTED]

So... you have about 8 connections? Your C program that reads lots of data, does it just connect once? By your description above it sounds like that is one connection.

If its more than one connection, are they connecting and disconnecting? I assume not, because they have so much to insert, they just stay connected.... then connection pooling wont help you.

I'd say (with what little info you have given) drop the connection pooling all together. Does not sound like you need it.

-Andy

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
      choose an index scan if your joining column's datatypes do not
      match

Reply via email to