| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org |
| Cc: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
| Subject: | Re: PgPool changes WAS: PostgreSQL clustering VS MySQL clustering |
| Date: | 2005-01-24 17:52:40 |
| Message-ID: | 200501240952.40183.josh@agliodbs.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Tatsuo,
> > Depends on your connection pooling software, I suppose. Most connection
> > pooling software only returns connections to the pool after a user has
> > been inactive for some period ... generally more than 3 seconds. So
> > connection continuity could be trusted.
>
> Not sure what you mean by "most connection pooling software", but I'm
> sure that pgpool behaves differently.
Ah, clarity problem here. I'm talking about connection pooling tools from
the client (webserver) side, such as Apache::DBI, PHP's pg_pconnect,
Jakarta's connection pools, etc. Not pooling on the database server side,
which is what pgPool provides.
Most of these tools allocate a database connection to an HTTP/middleware
client, and only release it after a specific period of inactivity. This
means that you *could* count on "web-user==connection" for purposes of
switching back and forth to the master -- as long as the connection-recycling
timeout were set higher than the pgPool switch-off period.
--
Josh Berkus
Aglio Database Solutions
San Francisco
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ragnar Hafstað | 2005-01-24 18:24:05 | Re: PgPool changes WAS: PostgreSQL clustering VS MySQL |
| Previous Message | Marty Scholes | 2005-01-24 15:45:57 | Re: PostgreSQL clustering VS MySQL clustering |