Hello,
I'm wondering if some other people here have some wisdom about this case
a few people have run into, apparently with no resolution.
Newer versions of DBD::Pg and PostgreSQL support a feature called
"server side prepares", which is supposed to give a significant
performance boost in so
this is more of a discussion post than a response:
On Aug 5, 2006, at 10:02 AM, Mark Stosberg wrote:
do you have links of that in regards to dbd::pg? i didn't realize
they supported it.
However, when deploying it on mod_perl on a busy website, I quickly
saw a lot of this kind of error:
Mark Stosberg wrote:
Hello,
I'm wondering if some other people here have some wisdom about this case
a few people have run into, apparently with no resolution.
Newer versions of DBD::Pg and PostgreSQL support a feature called
"server side prepares", which is supposed to give a significant
David Dick wrote:
Mark Stosberg wrote:
Hello,
I'm wondering if some other people here have some wisdom about this
case a few people have run into, apparently with no resolution.
Newer versions of DBD::Pg and PostgreSQL support a feature called
"server side prepares", which is supposed
On Sat, 2006-08-05 at 09:02 -0500, Mark Stosberg wrote:
> However, when deploying it on mod_perl on a busy website, I quickly saw
> a lot of this kind of error:
>
> prepared statement "dbdpg_7" already exists
Do you use prepare_cached? You might want to try that, with a 3 for the
$if_active par
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Newer versions of DBD::Pg and PostgreSQL support a feature called
> "server side prepares", which is supposed to give a significant
> performance boost in some cases.
>
> However, when deploying it on mod_perl on a busy website, I quickly saw
> a l
Perrin Harkins wrote:
On Sat, 2006-08-05 at 09:02 -0500, Mark Stosberg wrote:
However, when deploying it on mod_perl on a busy website, I quickly saw
a lot of this kind of error:
prepared statement "dbdpg_7" already exists
Do you use prepare_cached? You might want to try that, with a 3 for
I found a related mention of this issue here:
http://fudforum.org/forum/index.php?t=msg&th=4598&start=0&;
There the fix involved putting using DEALLOCATE when persistent
first, the patch with DEALLOCATE makes prepared statements entirely
useless, as it means you're caching a prepared statement
On Sat, 2006-08-05 at 18:46 -0500, Mark Stosberg wrote:
> So are you suggesting I should use:
>
> $dbh->prepare_cached($sql, { pg_server_prepare => 1 }, 3)
>
> ...throughout the web-app?
If you use prepare_cached, adding the 3 is the safest way to go. It
avoids possible problems with accidental
