Ernst Bachmann wrote:
If PQexecParams uses the unnamed statement (it appears to), this
shouldn't happen -- planning of the unnamed statement is delayed until
the first set of parameter values is bound. This behaviour started in 8.0.

What's the query?

Are you definitely using PQexecParams() and not PQexecPrepared()?

-O

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)

On 2005-07-05, Oliver Jowett <oliver (AT) opencloud (DOT) com> wrote:
The problem is that even with the unnamed statement and deferred planning,
the planner still has to treat the parameters as variables, not constants,
since nothing in the protocol stops you from running multiple portals from
the unnamed statement. This can make a significant difference, especially
where function calls are involved and major optimizations can be made on
constant values as a result of inlining.

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

Andrew - Supernews wrote:

Sure, expression optimization is less aggressive, but is that on its own
really going to produce a 100-fold difference in query execution?

The main problem pre-8.0 (or with named statements) is that index
selectivity estimates go out the window with a parameterized query, so a
much more general (and slower) plan gets chosen. The 8.0
unnamed-statement behaviour glues the actual parameter values into the
selectivity estimates so in theory you should get the same plan for the
unparameterized and parameterized-unnamed-statement cases.

This is why I'd like to see the actual query..

-O

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

On 2005-07-06, Oliver Jowett <oliver (AT) opencloud (DOT) com> wrote:
Sure. Only for specific types of queries, of course.

correct so far...

But that doesn't follow, since selectivity estimation isn't the only
factor.

Yes, it would certainly help.

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Oliver Jowett <oliver (AT) opencloud (DOT) com> writes:
It's certainly possible, depending on query details. Personally, I
ignored the original report in this thread as being utterly content
free...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Tom Lane wrote:
Andrew pointed out in some offlist discussion that it's actually more
than just expression optimization via eval_const_expressions; there are
some other cases where the tree is transformed differently if you have a
Const vs. Param in ways that estimate_expression_value() doesn't deal with:

- predicate_implied_by_simple_clause can remove parts of an expression
based on the actual (not estimated) values involved;
- match_special_index_operator manipulates LIKE/regexp/etc expressions
based on the actual patterns provided;
- LIMIT/OFFSET modifications to query cost only kick in with Consts.

I can't see any simple way to fix the first two since they change the
meaning of the expression, but the LIMIT/OFFSET query cost code could in
theory use estimate_expression_value().

-O

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org