From: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com> |
---|---|
To: | "alex b(dot)" <mailinglists1(at)gmx(dot)de> |
Cc: | Postgresql General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: caching query results |
Date: | 2003-05-23 16:10:39 |
Message-ID: | Pine.LNX.4.33.0305231007400.27073-100000@css120.ihs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Before investing a great deal of time in connection pooling, make sure you
actually need it. You may get better performance for less work / hassle
by just using a temporary table to hold the result set you wanna walk
through.
Persistant connections are, generaly 1000 times (or more) faster at
establishing than non-persistant, but when non-persistant connects only take about
1/10,000 of a second, it's no great gain speed wise to have persistant
connects.
And most pooling systems still don't guarantee that you'll get the same
connect back each time.
On Fri, 23 May 2003, alex b. wrote:
> hello!
>
> yes, I have already found out, that a transaction is over with each
> CGI-connection and its disconnection...
>
> now, I'd be interested in that connection pooling... any ideas, where
> I'd have to start?
>
> TIA
>
>
> scott.marlowe wrote:
> > On Wed, 21 May 2003, alex b. wrote:
> >
> >
> >>hello dear people without shaved necks!
> >>
> >>as many of you have already told me cursors are the way to go - now I know!
> >>
> >>there it is, kindly provided my BILL G.:
> >>
> >> BEGIN;
> >> DECLARE <cursorname> FOR <query>;
> >> FETCH <number_of_rows> FROM <cursorname>;
> >> MOVE {FORWARD|BACKWARD} <number_of_rows> IN <cursorname>;
> >>
> >>
> >>THANK YOU ALL VERY VIEL (much in german)!!!
> >>
> >>I will now have to implement session ID's into my CGI's...
> >>
> >>oh by the way... lets say a transaction has begun and was never
> >>commited.. what will happen to it?
> >>
> >>is there a automatic rollback after a certain time?
> >>or would there be ton's of open transactions?
> >
> >
> > Well, transactions can't stay open across a disconnect / reconnect, so
> > you'll have to use some kind of connection pooling to ensure they stay
> > open between invocations of your cgi scripts.
> >
> > What environment are you developing in? Java has pretty good connection
> > pooling, and so does PERL. PHP, not so good, but you can work around it
> > if you understand the underlying, uber simple persistant connection
> > methodology.
> >
> > There may be some open source connection pooling packages that can hold
> > the transactions open for your cgi scripts, but I've not played with
> > actual CGI in a few years now, so I have no clue how well any thing like
> > that would work.
> >
> >
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | scott.marlowe | 2003-05-23 16:11:40 | Re: caching query results |
Previous Message | scott.marlowe | 2003-05-23 15:52:56 | Re: deadlocks problem |