* 高健 (luckyjack...@gmail.com) wrote:
> Is there any common calculation methods for deciding the max_connections
> value?
max_connections is a hard limit and so you'd want to have that higher
than the number of connections you actually expect to have. The general
recommendation is to have the same
Thanks a lot!
I have understand this now.
And the following:
>In general you only want to have as many actual connections to PG
>as you have CPU cores in your database server.
This made me consider the appropriate value for max_conennections.
This might be another topic I think.
I am wo
* 高健 (luckyjack...@gmail.com) wrote:
> So I can draw a conclusion:
>
> Prepared statement is only for use in the same session at which it has
> been executed.
Prepared statements are session-local.
> It can not be shared via multiple sessions.
Correct.
> That is, when in some special situati
高健 wrote:
> Prepared statement is only for use in the same session at which it has been
> executed.
> It can not be shared via multiple sessions.
That is correct, see
http://www.postgresql.org/docs/current/static/sql-prepare.html
> That is, when in some special situations ,
> if I have to use
Hello everybody:
Sorry for disturbing.
I experience the prepared statement of postgresql via psql and have one
question:
In terminal A:
I prepared:
postgres=# prepare test(int) AS
postgres-# select * from customers c where c.cust_id = $*1*;
PREPARE
postgres=#
Then run:
postgres=# e
On Tue, Jun 29, 2010 at 3:23 PM, Vibhor Kumar wrote:
> On 28/06/10 11:14 PM, raghu ram wrote:
>
>>
>> Hi,
>>
>>
>>
>> We are using pgool-II version 2.3.2.2 (tomiteboshi)and postgres 8.3.9 and
>> facing the below error while running the select queries in the application
>> side::
>>
>>
>> ERROR:
On 28/06/10 11:14 PM, raghu ram wrote:
Hi,
We are using pgool-II version 2.3.2.2 (tomiteboshi)and postgres 8.3.9
and facing the below error while running the select queries in the
application side::
ERROR: prepared statement
"mdb2_statement_pgsql_71417ca02c1aa9cec1dd2570c46e992e" does
Hi,
We are using pgool-II version 2.3.2.2 (tomiteboshi)and postgres 8.3.9 and
facing the below error while running the select queries in the application
side::
ERROR: prepared statement
"mdb2_statement_pgsql_71417ca02c1aa9cec1dd2570c46e992e" does not exist
STATEMENT: DEALLOCATE PREPARE
md
On Tue, Dec 9, 2008 at 8:59 PM, Chris <[EMAIL PROTECTED]> wrote:
> Richard Huxton wrote:
>>
>> WireSpot wrote:
>>>
>>> This mechanism is still not perfect. Technically it is still possible
>>> for race conditions to appear. Apparently (in PHP at least) pg_connect
>>> does persistent connections by
Richard Huxton wrote:
WireSpot wrote:
This mechanism is still not perfect. Technically it is still possible
for race conditions to appear. Apparently (in PHP at least) pg_connect
does persistent connections by default.
Nope - pg_pconnect() does that. Multiple calls to pg_connect() within
the s
WireSpot wrote:
> This mechanism is still not perfect. Technically it is still possible
> for race conditions to appear. Apparently (in PHP at least) pg_connect
> does persistent connections by default.
Nope - pg_pconnect() does that. Multiple calls to pg_connect() within
the same script will give
On Mon, Dec 8, 2008 at 09:17, Tomasz Ostrowski <[EMAIL PROTECTED]> wrote:
> So:
>
> sql_md5 = md5(sql);
> try {
>PREPARE sql_md5 AS sql;
> } catch (SQLException e) {
>if (! e.getSQLState().equals("42P05")) {
>throw e;
>}
> }
> EXECUTE sql_md5;
Yeah, well, li
On 2008-11-20 12:56, WireSpot wrote:
On Thu, Nov 20, 2008 at 10:56, Albe Laurenz <[EMAIL PROTECTED]> wrote:
Do you still need the old prepared statement?
If not, you can simple DEALLOCATE it and then try the PREPARE again.
Yes, I'd like to keep the old statements, that's part of the perks --
Alvaro Herrera wrote:
In this case, why not just prepare all the needed statements at the
first use of the session by the pool software?
In theory yes, but I can't imagine how it could be done in practice.
The pool software is typically a middleware and the application isn't
even awa
Daniel Verite wrote:
> Also contrary to prepared statements, maybe that cache would be shared
> between connections, and that would be excellent, since it fits the
> typical usage pattern of websites: a high-throughput of a small set of
> low-latency queries, fired from pooled connections.
WireSpot wrote:
So it would eliminate the possibility of clashes, but do nothing for
statement reuse.
Agreed.
What would make it all the way better was if the database would do
that last step for you as well: automatically recognize statements
that do the same thing and return the a
On Fri, Nov 21, 2008 at 09:55:11AM +0200, WireSpot wrote:
> What would make it all the way better was if the database would do
> that last step for you as well: automatically recognize statements
> that do the same thing and return the already existing handle.
This is somewhat difficult; things to
On Thu, Nov 20, 2008 at 19:19, Daniel Verite <[EMAIL PROTECTED]> wrote:
> By the way, why do the prepared statements require to be named at all?
> With other DBMS such as oracle or mysql, one can prepare statements without
> providing any name for them: the prepare() step returns a "statement handl
Albe Laurenz wrote:
You'll have to find a way to pick or generate unique names for the
prepared statements.
You could check for name collisions and disambiguate with a suffix
or something.
By the way, why do the prepared statements require to be named at all?
With other DBMS such as or
On Thu, Nov 20, 2008 at 16:07, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> I guess if connections are persistent, you could clear them before each
> usage with DISCARD (8.3 only)
Again, I'd be losing the advantage of the already prepared statements.
Basically, what it comes down it is I want to be
On Thu, Nov 20, 2008 at 04:03:08PM +0200, WireSpot wrote:
> On Thu, Nov 20, 2008 at 15:45, Sam Mason <[EMAIL PROTECTED]> wrote:
> > Have you thought about using stored procedures instead of prepared
> > statements? No need to register them or keep track of that state.
>
> I'm not sure if it would
WireSpot escribió:
> I guess he means if connections are persistent, or if the same
> connection is being used at the same time from different parts of the
> application.
I guess if connections are persistent, you could clear them before each
usage with DISCARD (8.3 only)
--
Alvaro Herrera
On Thu, Nov 20, 2008 at 15:45, Sam Mason <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 19, 2008 at 09:42:33PM +0200, WireSpot wrote:
>> I also imagined some workarounds in the code (PHP), such as defining a
>> global/static hash table and registering statement names with it. But
>> I'd like to know if t
On Wed, Nov 19, 2008 at 09:42:33PM +0200, WireSpot wrote:
> I also imagined some workarounds in the code (PHP), such as defining a
> global/static hash table and registering statement names with it. But
> I'd like to know if there's a better way.
Have you thought about using stored procedures inst
> Merlin Moncure escribió:
>> pg_prepared_statements (on recent versions of postgresql)
Thank you, that's one of the things I wanted to know.
On Thu, Nov 20, 2008 at 15:30, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> Merlin Moncure escribió:
>> also, watch out for race conditions.
>
> What race c
Merlin Moncure escribió:
> On Wed, Nov 19, 2008 at 2:42 PM, WireSpot <[EMAIL PROTECTED]> wrote:
> > 3) Reading a list of all the currently defined prepared statements to
> > see if the one I want is already prepared. I'm hoping some "magic"
> > SELECT in pg's internal tables may do the trick. But
Please, send your replies to the list as well.
WireSpot wrote:
> > Do you still need the old prepared statement?
> >
> > If not, you can simple DEALLOCATE it and then try the PREPARE again.
>
> Yes, I'd like to keep the old statements, that's part of the perks --
> if a query will be repeated it
On Wed, Nov 19, 2008 at 2:42 PM, WireSpot <[EMAIL PROTECTED]> wrote:
> I'm trying to use prepared statements in an application and I'm
> running into this error: "Query failed: prepared statement already
> exists".
>
> The reason is obvious. What I want to know is the best way to avoid
> getting th
On Thu, Nov 20, 2008 at 10:56, Albe Laurenz <[EMAIL PROTECTED]> wrote:
> Do you still need the old prepared statement?
>
> If not, you can simple DEALLOCATE it and then try the PREPARE again.
Yes, I'd like to keep the old statements, that's part of the perks --
if a query will be repeated it will
WireSpot wrote:
> I'm trying to use prepared statements in an application and I'm
> running into this error: "Query failed: prepared statement already
> exists".
>
> The reason is obvious. What I want to know is the best way to avoid
> getting this error. The client application sets statement name
I'm trying to use prepared statements in an application and I'm
running into this error: "Query failed: prepared statement already
exists".
The reason is obvious. What I want to know is the best way to avoid
getting this error. The client application sets statement names as MD5
of the actual query
Jason L. Buberel wrote:
> Can someone point me to an example of creating a prepared
> statement for a query with an 'IN' clause?
>
> The query looks like this:
>
> select value from table where
> state = $1 and city = $2 and zip = $3 and
> date in ( $4 );
>
> For the prepared statement, I have
On Wed, Oct 17, 2007 at 07:37:15AM -0700, Jason L. Buberel wrote:
> Can someone point me to an example of creating a prepared statement for a
> query with an 'IN' clause?
>
> The query looks like this:
>
> select value from table where
> state = $1 and city = $2 and zip = $3 and
> date in ( $4 );
Can someone point me to an example of creating a prepared statement for
a query with an 'IN' clause?
The query looks like this:
select value from table where
state = $1 and city = $2 and zip = $3 and
date in ( $4 );
For the prepared statement, I have tried:
prepare st1(text, text, text, text[
On Sun, Aug 13, 2006 at 10:48:37AM -0700, Jim Bryan wrote:
> Hi! In a function to insert rows into a table, I keep
> getting ERROR: prepared statement "updateplan" already
> exists. If any ideas; thanks.
As the error says, you already have a prepared statement named
"updateplan". To reuse that
Hi! In a function to insert rows into a table, I keep
getting ERROR: prepared statement "updateplan" already
exists. If any ideas; thanks.
CREATE OR REPLACE FUNCTION testPreparedStatement()
RETURNS SETOF FLOAT AS $$
DECLARE
tryint1 int4:=1 ;
tryint2 int4:=2 ;
BEGIN
PREPARE updatePlan
Michael Fuhr wrote:
On Tue, Jan 17, 2006 at 03:37:14PM -0500, David Rysdam wrote:
I have a Tcl function that does this:
1) create prepared statement for binary insertion via pg_exec (and
releases the result handle)
2) run statement with binary data via pg_exec_prepared (and releases the
r
On Tue, Jan 17, 2006 at 03:37:14PM -0500, David Rysdam wrote:
> I have a Tcl function that does this:
>
> 1) create prepared statement for binary insertion via pg_exec (and
> releases the result handle)
> 2) run statement with binary data via pg_exec_prepared (and releases the
> result handle)
>
I have a Tcl function that does this:
1) create prepared statement for binary insertion via pg_exec (and
releases the result handle)
2) run statement with binary data via pg_exec_prepared (and releases the
result handle)
3) deallocate statement via pg_exec (and releases the result handle)
Whe
On Sat, Dec 11, 2004 at 12:30:30PM +, NosyMan wrote:
> I want to know that is a posibillity to test if a statement is prepared in
> PL/PgSQL.
>
> I have create a function:
> .
> PREPARE PSTAT_SAVE_record(INTEGER, INTEGER, DATE, VARCHAR) AS INSERT INTO
> table VALUES($1, $2, $3, $4)
Hi there,
I want to know that is a posibillity to test if a statement is prepared in
PL/PgSQL.
I have create a function:
.
PREPARE PSTAT_SAVE_record(INTEGER, INTEGER, DATE, VARCHAR) AS INSERT INTO
table VALUES($1, $2, $3, $4);
.
When I try to execute it second time I got an er
41 matches
Mail list logo
