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
Hi- where can I find location of the DBT presentation in Portland next week?
Thanks-
Lee
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 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:
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
17 matches
Mail list logo
