2009/3/14 decibel deci...@decibel.org
On Mar 10, 2009, at 12:20 PM, Tom Lane wrote:
f...@redhat.com (Frank Ch. Eigler) writes:
For a prepared statement, could the planner produce *several* plans,
if it guesses great sensitivity to the parameter values? Then it
could choose amongst them at
On Mar 9, 2009, at 8:36 AM, Mario Splivalo wrote:
Now, as I was explained on pg-jdbc mailinglist, that 'SET
enable_seqscan TO false' affects all queries on that persistent
connection from tomcat, and It's not good solution. So I wanted to
post here to ask what other options do I have.
On Mar 10, 2009, at 12:20 PM, Tom Lane wrote:
f...@redhat.com (Frank Ch. Eigler) writes:
For a prepared statement, could the planner produce *several* plans,
if it guesses great sensitivity to the parameter values? Then it
could choose amongst them at run time.
We've discussed that in the
Tom Lane t...@sss.pgh.pa.us writes:
Mario Splivalo mario.spliv...@megafon.hr writes:
Now I'm confused, why is 'sql' function much slower than 'direct' SELECT?
Usually the reason for this is that the planner chooses a different plan
when it has knowledge of the particular value you are
f...@redhat.com (Frank Ch. Eigler) writes:
For a prepared statement, could the planner produce *several* plans,
if it guesses great sensitivity to the parameter values? Then it
could choose amongst them at run time.
We've discussed that in the past. Choose at runtime is a bit more
easily
I have a function, looking like this:
CREATE OR REPLACE FUNCTION get_memo_display_queue_size(a_service_id integer)
RETURNS integer AS
$BODY$
SELECT
COUNT(*)::integer
FROM
v_messages_memo
LEFT JOIN messages_memo_displayed
ON id = message_id
WHERE
Mario Splivalo mario.spliv...@megafon.hr writes:
Now I'm confused, why is 'sql' function much slower than 'direct' SELECT?
Usually the reason for this is that the planner chooses a different plan
when it has knowledge of the particular value you are searching for than
when it does not. I
Tom Lane tgl 'at' sss.pgh.pa.us writes:
Mario Splivalo mario.spliv...@megafon.hr writes:
Now I'm confused, why is 'sql' function much slower than 'direct' SELECT?
Usually the reason for this is that the planner chooses a different plan
when it has knowledge of the particular value you are
On Mon, Mar 9, 2009 at 5:51 PM, Guillaume Cottenceau g...@mnc.ch wrote:
Until it's possible to specifically tell the JDBC driver (and/or
PG?) to not plan once for all runs (or is there something better
to think of?), or the whole thing would be more clever (off the
top of my head, PG could try
Guillaume Smet guillaume.s...@gmail.com writes:
Unnamed prepared statements are planned after binding the values,
starting with 8.3, or more precisely starting with 8.3.2 as early 8.3
versions were partially broken on this behalf.
No, 8.2 did it too (otherwise we wouldn't have considered 8.3.0
Tom Lane schrieb:
Guillaume Smet guillaume.s...@gmail.com writes:
Unnamed prepared statements are planned after binding the values,
starting with 8.3, or more precisely starting with 8.3.2 as early 8.3
versions were partially broken on this behalf.
No, 8.2 did it too (otherwise we wouldn't
Tom Lane wrote:
Mario Splivalo mario.spliv...@megafon.hr writes:
Now I'm confused, why is 'sql' function much slower than 'direct' SELECT?
Usually the reason for this is that the planner chooses a different plan
when it has knowledge of the particular value you are searching for than
when
Guillaume Cottenceau wrote:
Now I'm confused, why is 'sql' function much slower than 'direct' SELECT?
Usually the reason for this is that the planner chooses a different plan
when it has knowledge of the particular value you are searching for than
when it does not.
Yes, and since Mario is
Mario Splivalo mario.spliv...@megafon.hr writes:
Is this difference normal?
It's hard to tell, because you aren't comparing apples to apples.
Try a prepared statement, like
prepare foo(int) as
SELECT
COUNT(*)::int4
FROM
_v1
WHERE
service_id = $1
;
execute foo(504);
On Mon, Mar 9, 2009 at 1:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Guillaume Smet guillaume.s...@gmail.com writes:
Unnamed prepared statements are planned after binding the values,
starting with 8.3, or more precisely starting with 8.3.2 as early 8.3
versions were partially broken on this
The driver will use unnamed statements for all statements until it
sees the same statement N times where N is 5 I believe, after that it
uses a named statement.
Shame there's no syntax for it to pass the a table of the parameters to
the server when it creates the named statement as
1. And how do you do that from JDBC? There is no standard concept of
'unnamed' prepared statements in most database APIs, and if there were the
behavior would be db specific. Telling PG to plan after binding should be more
flexible than unnamed prepared statements - or at least more
Tom Lane wrote:
Mario Splivalo mario.spliv...@megafon.hr writes:
Is this difference normal?
It's hard to tell, because you aren't comparing apples to apples.
Try a prepared statement, like
[...cut...]
which should produce results similar to the function. You could
then use explain analyze
Mario Splivalo mario.spliv...@megafon.hr writes:
So, it is the same. When I do EXPLAIN ANALYZE EXECUTE I get completely
different execution plan:
...
- Bitmap Heap Scan on messages
(cost=287.98..21192.42 rows=12848 width=4) (actual time=0.049..0.169
rows=62 loops=1)
On 3/9/09 1:40 PM, Oliver Jowett oli...@opencloud.com wrote:
Scott Carey wrote:
1. And how do you do that from JDBC? There is no standard concept of
I've suggested that as a protocol-level addition in the past, but it
would mean a new protocol version. The named vs. unnamed statement
20 matches
Mail list logo
