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
On Mar 9, 2009, at 7:28 AM, Lee Hughes wrote:
Hi- where can I find location of the DBT presentation in Portland
next week?
It'll be at Portland State University at 7pm Thursday March 12. It's
in the Fourth Avenue Building (FAB) room 86-01, on 1900 SW 4th Ave.
It's in G-10 on the map: h
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
Hi- where can I find location of the DBT presentation in Portland next week?
Thanks-
Lee
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
17 matches
Mail list logo
