Re: question on backends

From: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
To: "Luis Alberto Amigo Navarro" <lamigo(at)atc(dot)unican(dot)es>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: question on backends
Date: 2002-07-29 15:28:54
Message-ID: 005101c23714$a7126770$0200a8c0@SOL
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

libpq has a function pconnect as opposed to connect that will do it. PHP and most other interfaces will let you use persistent connections.

Chris
----- Original Message -----
From: Luis Alberto Amigo Navarro
To: Christopher Kings-Lynne ; pgsql-hackers(at)postgresql(dot)org
Sent: Monday, July 29, 2002 7:00 PM
Subject: Re: [HACKERS] question on backends

How?
----- Original Message -----
From: Christopher Kings-Lynne
To: Luis Alberto Amigo Navarro ; pgsql-hackers(at)postgresql(dot)org
Sent: Monday, July 29, 2002 12:36 PM
Subject: Re: [HACKERS] question on backends

Just use persistent connections.

Chris
----- Original Message -----
From: Luis Alberto Amigo Navarro
To: pgsql-hackers(at)postgresql(dot)org
Sent: Monday, July 29, 2002 5:32 PM
Subject: [HACKERS] question on backends

Hi all
As I understand every time there is a request to postgres a new backend is made, and when the request is finished, even if the connection is already active the backend dies. I wonder if is there any parameter that allow backends to remain beyond a transaction. Creating a new backend every time a transaction is made means forking the code and reallocating sort_memory. Although it is not a high resource usage, on short transactions as OLTPs it is a relevant work time, I think it would be interesting that a predefined number of backends were allowed to remain active beyond the transaction.
Thanks and Regards

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2002-07-29 15:30:59 Re: anonymous composite types for Table Functions (aka
Previous Message Neil Conway 2002-07-29 15:24:06 Re: anonymous composite types for Table Functions (aka SRFs)