From: | "Matt Clark" <matt(at)ymogen(dot)net> |
---|---|
To: | "'Tatsuo Ishii'" <t-ishii(at)sra(dot)co(dot)jp> |
Cc: | <pg(at)rbt(dot)ca>, <awerman2(at)hotmail(dot)com>, <scottakirkwood(at)gmail(dot)com>, <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Caching of Queries |
Date: | 2004-10-05 15:35:28 |
Message-ID: | 012501c4aaf0$f12d0930$8300a8c0@solent |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> I don't know what you are exactly referring to in above URL
> when you are talking about "potential pitfalls of pooling".
> Please explain more.
Sorry, I wasn't implying that pgpool doesn't deal with the issues, just that
some people aren't necessarily aware of them up front. For instance, pgpool
does an 'abort transaction' and a 'reset all' in lieu of a full reconnect
(of course, since a full reconnect is exactly what we are trying to avoid).
Is this is enough to guarantee that a given pooled connection behaves
exactly as a non-pooled connection would from a client perspective? For
instance, temporary tables are usually dropped at the end of a session, so a
client (badly coded perhaps) that does not already use persistent
connections might be confused when the sequence 'connect, create temp table
foo ..., disconnect, connect, create temp table foo ...' results in the
error 'Relation 'foo' already exists'.
From | Date | Subject | |
---|---|---|---|
Next Message | Bill Montgomery | 2004-10-05 16:21:40 | Excessive context switching on SMP Xeons |
Previous Message | Chris Hutchinson | 2004-10-05 06:49:26 | EXPLAIN ANALYZE much slower than running query normally |