Re: [ADMIN] When postgres will be faster?

From: sk(dot)list(at)comset(dot)net
To: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
Cc: pgsql-hackers(at)postgreSQL(dot)org, pgsql-admin(at)postgreSQL(dot)org, Marcin Mazurek - Multinet SA - Poznan <m(dot)mazurek(at)multinet(dot)pl>
Subject: Re: [ADMIN] When postgres will be faster?
Date: 1999-11-30 15:11:36
Message-ID: XFMail.991130181136.sk.list@comset.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)comset(dot)net
http://www.comset.net
--------------------------

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Theo Kramer 1999-11-30 15:34:12 Re: [HACKERS] Insert into view
Previous Message Tom Lane 1999-11-30 15:07:59 Re: [HACKERS] Insert into view