Hello again, Now that I have working the Extended Query using the Front End Protocol 3.0, I'm getting better results with simple queries than extended queries. table comptes: Simple query: select * from comptes WHERE codi_empresa = '05' AND nivell=11 and clau_compte like '05430%' => 0,0273 seconds for 14 rows Extened Query: 111074 rows All three columns are indexed. Parse: select * from comptes WHERE codi_empresa = $1 AND nivell=$2 and clau_compte like $3 Bind + Execute + Sync in the same packet connection: 05,11,05430% => 0.1046 for 10 rows I measure the time when binding + executing + Sync. I'm using prepared named statement and portals. The difference is really big ... In the docs I understand that using the unnamed prepared statement with parameters, is planned during the binding phase, but I'm using a prepared statement ... And later, in a Note, I can read: Note: Query plans generated from a parameterized query might be less efficient than query plans generated from an equivalent query with actual parameter values substituted. The query planner cannot make decisions based on actual parameter values (for example, index selectivity) when planning a parameterized query assigned to a named prepared-statement object. This possible penalty is avoided when using the unnamed statement, since it is not planned until actual parameter values are available. The cost is that planning must occur afresh for each Bind, even if the query stays the same. And now it's not clear to me nothing at all ... What are the advantages of using the extended query ? thanks, regards, raimon -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
