Re: Caching of Queries

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'.

In response to

Responses

Browse pgsql-performance by date

  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