On 07.07.2017 21:24, NetVicious via Firebird-devel wrote:
HI!
I don't know if this it's thegood place to send this message.
We have a bug on PHP from version 7.0 to today related to multiple
connections to a firebird database.
I don't know if here it's any developer who can help all the PH
HI!
I don't know if this it's thegood place to send this message.
We have a bug on PHP from version 7.0 to today related to multiple connections
to a firebird database.
I don't know if here it's any developer who can help all the PHP developers to
fix this bug.
Check the bug on bugs.php.net
https
On 07.07.2017 17:06, marius adrian popa wrote:
It doesn't work , the same
Marius did you try fresh B3_0_Release? Checked out after 23 of May?
I've made a change fixing non-SSE operation, and emulated use of non-SSE
machine, and it worked for me.
But I need your confirmation that issue is f
07.07.2017 18:26, Adriano dos Santos Fernandes wrote:
BTW, isn't ConditionalStream used for something in this field?
Yep, but the optimizer so far handles just one specific case (A = ? or ?
is null). It could be extended though.
Dmitry
-
> To evaluate COALESCE, e.emp_no must be known.
Why?
Is it not really the case that for all practical purposes the COALESCE will
always return a value
How else could COALESCE(?, NULL ) [Example #3] use an index?
{Nothing says that the input parameter won't be NULL}
Sean
-
On 07/07/2017 12:19, Dmitry Yemanov wrote:
> 07.07.2017 18:12, Dimitry Sibiryakov wrote:
>>
>> In this particular case it is enough to know parameter value to
>> choose plan. Parameters are known before reading table.
>
> True, but our optimizer is developed for generic cases, not such
> specific o
07.07.2017 18:12, Dimitry Sibiryakov wrote:
In this particular case it is enough to know parameter value to
choose plan. Parameters are known before reading table.
True, but our optimizer is developed for generic cases, not such
specific ones. It could be improved, but I'd say we have more i
07.07.2017 17:07, Dmitry Yemanov wrote:
Given
where e.EMP_NO = COALESCE(?, e.emp_no )
and that there is an index on EMP_NO, why doesn't the optimiser default
to the index. After all, it is logically more likely that a value will
be passed in the where condition, rather than a NULL.
To eval
07.07.2017 17:51, Paul Reeves wrote:
But that doesn't answer all my questions...
Given
where e.EMP_NO = COALESCE(?, e.emp_no )
and that there is an index on EMP_NO, why doesn't the optimiser default
to the index. After all, it is logically more likely that a value will
be passed in the whe
On Fri, 7 Jul 2017 11:27:26 -0300 Adriano dos Santos Fernandes wrote
> >
> It does not evaluate COALESCE at prepare time.
>
> It's just a expression which may or may not contain fields.
>
> If it doesn't contain fields, it will be the same as a simple "?" for
> the plan calculation purposes.
>
On 07/07/2017 11:19, Paul Reeves wrote:
> Given this simple SQL statement
>
> select e.emp_no, e.full_name
> from employee e
> where e.emp_no = coalesce(value1,value2 )
>
> the plan varies depending on the following :
>
> 1. where e.EMP_NO = COALESCE(?, ? ) -- PLAN (E INDEX (RDB$PRIMARY7))
>
Given this simple SQL statement
select e.emp_no, e.full_name
from employee e
where e.emp_no = coalesce(value1,value2 )
the plan varies depending on the following :
1. where e.EMP_NO = COALESCE(?, ? ) -- PLAN (E INDEX (RDB$PRIMARY7))
2. where e.EMP_NO = COALESCE(2, ? ) -- PLAN (E INDEX
It doesn't work , the same
On Thu, May 18, 2017 at 1:18 PM, Doychin Bondzhev
wrote:
> I think this
>
> p = (UCHAR*) &hash_value;
>
> can be taken before while loop and also removed few lines later.
>
>
>
> On 18.5.2017 г. 10:57 ч., marius adrian popa wrote:
>
>> firebird 3.0.3 current crashes on
13 matches
Mail list logo
