2009/3/14 decibel
> 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
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 pas
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.
FWI
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
Tom Lane writes:
> Mario Splivalo 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 su
On 3/9/09 1:40 PM, "Oliver Jowett" 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
behaviour was an attem
Mario Splivalo 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)
>
Tom Lane wrote:
> Mario Splivalo 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 execute" to prob
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 transpa
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 planne
On Mon, Mar 9, 2009 at 1:16 PM, Tom Lane wrote:
> Guillaume Smet 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 (othe
Mario Splivalo 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);
which should produce results
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
Tom Lane wrote:
> Mario Splivalo 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 supp
Tom Lane schrieb:
Guillaume Smet 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 to b
Guillaume Smet 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 to be
broken...). Th
On Mon, Mar 9, 2009 at 5:51 PM, Guillaume Cottenceau 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 to repl
Tom Lane writes:
> Mario Splivalo 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.
Yes,
Mario Splivalo 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 suppose 'service_id' has a very
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
s
20 matches
Mail list logo
