On Mon, 23 Jan 2006 10:23:17 -0600
"Dave Dutcher" <[EMAIL PROTECTED]> wrote:
> I don't think pgpool is what you need. If I understand pgpool
> correctly, pgpool lets you pool multiple postgres servers together.
> You are just looking for database connection pooling.
While pgpool can let you
imum numbers of open
connections.
Dave
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marcos
Sent: Monday, January 23, 2006 7:27 AM
To: Markus Schaber
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] [PERFORMANCE] Stored Procedures
Hi Markus
Hi Markus
> You really should consider using a connection pool (most web application
> servers provide pooling facilities) or some other means to keep the
> connection between several http requests.
Yes. I'm finding a connection pool, I found the pgpool but yet don't
understand how it's work I'm
Hi, Marcos,
Marcos wrote:
> This one was my doubt, perhaps in based desktop applications this is
> true, but in web applications this is not the re-connecting is
> constant :(.
If this is true, then you have a much bigger performance problem than
query plan preparation.
You really should consid
Em Sex, 2006-01-20 às 15:34 -0600, Jim C. Nasby escreveu:
> On Fri, Jan 20, 2006 at 08:38:23PM +0100, Rikard Pavelic wrote:
> > This would solve problems with prepare which is per session, so for
> > prepared function to be
> > optimal one must use same connection.
>
> If you're dealing with some
Jim C. Nasby wrote:
If you're dealing with something that's performance critical you're not
going to be constantly re-connecting anyway, so I don't see what the
issue is.
I didn't include mailing list in my second reply :( so here it is again.
Someone may find this interesting...
http://arc
Jim C. Nasby wrote:
If you're dealing with something that's performance critical you're not
going to be constantly re-connecting anyway, so I don't see what the
issue is.
I really missed your point.
In multi user environment where each user uses it's connection for
identification
purposes,
On Fri, Jan 20, 2006 at 08:38:23PM +0100, Rikard Pavelic wrote:
> This would solve problems with prepare which is per session, so for
> prepared function to be
> optimal one must use same connection.
If you're dealing with something that's performance critical you're not
going to be constantly re
Jim C. Nasby wrote:
My college professor said it, it must be true! ;P
The famous joke ;)
My understanding is that in plpgsql, 'bare' queries get prepared and act
like prepared statements. IE:
SELECT INTO variable
field
FROM table
WHERE condition = true
;
Unfortunately I don
On Fri, Jan 20, 2006 at 07:50:23PM +0100, Rikard Pavelic wrote:
> >>Hi,
> >>
> >>Will simple queries such as "SELECT * FROM blah_table WHERE tag='x'; work
> >>any
> >>faster by putting them into a stored procedure?
>
> >
> >IMHO no, why do you think so? You can use PREPARE instead, if you have m
Hi,
Will simple queries such as "SELECT * FROM blah_table WHERE tag='x'; work any
faster by putting them into a stored procedure?
IMHO no, why do you think so? You can use PREPARE instead, if you have many
selects like this.
I tought that creating stored procedures in database means
stor
11 matches
Mail list logo
