Re: [ADMIN] When postgres will be faster? - Mailing list pgsql-hackers
From | sk.list@comset.net |
---|---|
Subject | Re: [ADMIN] When postgres will be faster? |
Date | |
Msg-id | XFMail.991130181136.sk.list@comset.net Whole thread Raw |
In response to | Re: [ADMIN] When postgres will be faster? (Oleg Bartunov <oleg@sai.msu.su>) |
Responses |
Re: [ADMIN] When postgres will be faster?
Re: [ADMIN] When postgres will be faster? |
List | pgsql-hackers |
Hi! On 29-Nov-99 Oleg Bartunov wrote: > I'm not concern very much about speed of Postgres but mostly > about its connection schema. Every new connect to database postgres > forks another children. It's impossible to work with different fork and fork/exec are some different. postmaster forks and execute backend binary. > databases. On my production site I work with persistent connections > between http (mod_perl) <-> postgres and quite satisfies with efficiency - > I have 20 httpd running and 20 db backends accordingly. > This requires some memory, but I could live. Now other developers I have >100 connections in peak load. Not all of them use postgres. If I use pconnect I lost my RAM ;-) > want to use postgres as a db backend in their Web applications and > also want to have persistence to some another databases. > If you have N databases and M httpd servers, you will end with > N*M DB backends. This is too much and I'm afraid my solution Why? Why N*M? After disconnect the persistent connection backend should not finish but next connection opens other bata base? Or i misunderstood? > I don't know if it's possible to have a pool of db childrens, > which connected to, say, template1 database and children could > switch to requested database on demand. This would require some > modification of DBD driver of course, but I think it's not hard. Hmmm... There is 2 ways to support pool. 1. FORK only. Postmaster and postgres are same binary. postmaster accept connection and forked. Parent creates structure with child pid, descriptors etc... Child becomes backend. When child finish the request it send signal (smem,fifo etc) to parent. Parent set IDLE flag to child structure. When next connection accepted parent seek through list of child to find first idle one. parent clear IDLE flag and fd_dup file descriptors to backend's. Child structure contain call counter and time stamp of start and last call time. If call counter exceeds N or time exceeds T all descriptors becomes closed. Child catch SIGPIPE on closed descriptors and finish. Parent scans list of structures and check time stamps to stop idle backends or start new one (to have pool of idle backends). 2. Fork/exec. I dont know. But it possible too. Same like previous. So, if backend works with one database only and cannot reconnect - add 'database' field to child structure described above. Or add keywords CONNECT/DISCONNECT to language. Hmm... I was sure backend can server more then 1 database sequentially. SKiller -------------------------- Sergei Keler WebMaster of "ComSet" E-Mail: skiller@comset.net http://www.comset.net --------------------------
pgsql-hackers by date: