Tom Lane wrote:
> Oliver Jowett <[EMAIL PROTECTED]> writes:
>
>>Sure, expression optimization is less aggressive, but is that on its own
>>really going to produce a 100-fold difference in query execution?
>
>
> It's certainly possible, depending on query details.
Andrew pointed out in some offl
Oliver Jowett <[EMAIL PROTECTED]> writes:
> Sure, expression optimization is less aggressive, but is that on its own
> really going to produce a 100-fold difference in query execution?
It's certainly possible, depending on query details. Personally, I
ignored the original report in this thread as
On 2005-07-06, Oliver Jowett <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews 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 mul
Andrew - Supernews 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
On 2005-07-05, Oliver Jowett <[EMAIL PROTECTED]> wrote:
> Ernst Bachmann wrote:
>> The following bug has been logged online:
>>
>> Bug reference: 1753
>> Logged by: Ernst Bachmann
>> Email address: [EMAIL PROTECTED]
>> PostgreSQL version: 8.0.3
>> Operating system: Linux
>> De
Ernst Bachmann wrote:
> The following bug has been logged online:
>
> Bug reference: 1753
> Logged by: Ernst Bachmann
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.0.3
> Operating system: Linux
> Description:Query Optimizer does not work well with libpg /
The following bug has been logged online:
Bug reference: 1753
Logged by: Ernst Bachmann
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.3
Operating system: Linux
Description:Query Optimizer does not work well with libpg /
PQexecParams
Details:
It looks like
