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
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
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 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
12 matches
Mail list logo
