Hello,
During a complex join between two tables that involve an OR operation, I
received the following error message:
!OS: The printer is out of paper.
This corresponds to error number 28 in Windows OS, yet in errno.h, 28 is
for ENOSPC, which is the expected one.
In the meanwhile, I fixed that join, replacing the complex condition that
included one OR into a UNION ALL (conditions made that possible),
but I think it's worth investigating possible optimization that would do
this internally (transforming join conditions using OR with plain UNION).
Anyway, if above suggestion is just something to think about (as long as it
always exists a solution in the hands of the SQL developer),
the winerror translation certainly requires a review. (mutils.c / int
winerror(int e));
Thank you,
Dan
Hi,
Just installing from source for the first time since quite a while :-)
On a FC30 system, using:
./configure --disable-debug --disable-developer --disable-assert
--enable-optimize
the bootstrap / configure steps did not complain about R-devel missing, but
then issuing make failed on not finding the Rembedded.h include.
Maybe the configure script needs a patch!
All fine after installing R-devel, thanks for great docs!
Cheers,
Arjen
--
====================================================================
ICIS, office M1.02.07 Radboud University
Mercator 1 Faculty of Science
Toernooiveld 212 arjen(a)cs.ru.nl
NL-6525 EC Nijmegen, The Netherlands +31-(0)24-365 2354
===================== http://www.informagus.nl/ ====================
Hello,
I am exploring MonetDB queries performance that are generated based on user
parameters/preferences.
To be more specific the where clause is generated based on a user interface
mapping user input parameters straight into SQL statements.
See below one example of this transformation.
FIELD contains PATTERN (case sensitive/insensitive)
is transformed into
select ... from TABLE where
(case when (user_case_sensitive_pref=1) then ("FIELD" like '%PATTERN%')
else ("FIELD" ilike '%PATTERN%')
end);
Performance of this in comparison with query generated from within the code:
char * query;
if ( user_case_sensitive_pref )
query = "select ... from TABLE where \"FIELD\" like '%PATTERN%'";
else
query = "select ... from TABLE where \"FIELD\" ilike '%PATTERN%'";
query_execute( query);
is huge (second approach takes 0.12 sec, vs 6 sec for first one).
But it requires a far more complex implementation.
First I thought this has to do with user variables but even if the
statement is
select ... from TABLE where
(case when TRUE then ("FIELD" like '%PATTERN%')
else ("FIELD" ilike '%PATTERN%')
end);
timing is similarly slow.
This narrows down to "case" performance issue, as far as I can see.
Am I wrong?
Thank you,
Dan
