Problem/Bug: "SELECT 5 / 2;" returns 2 ?

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Problem/Bug: "SELECT 5 / 2;" returns 2 ?

Jay Sprenkle
On 9/30/05, Ralf Junker <[hidden email]> wrote:

>
> Quite right, but even with explicit typing there are cases where SQLite3
> can not be instructed to store REAL numbers as REALs:
>
> C:\>sqlite3 num.db3
> SQLite version 3.2.1
> Enter ".help" for instructions
> sqlite> CREATE TABLE i (a INTEGER, b INTEGER);
> sqlite> INSERT INTO i VALUES (5, 2);
> sqlite> SELECT a / b FROM i;
> 2
> sqlite> INSERT INTO i VALUES (5.0, 2.0);
> sqlite> SELECT a / b FROM i;
> 2
> 2
>
> Even though the 2nd insert explicitly types 5.0 and 2.0 as REALs, they are
> stored as INTEGERs internally and resuls in incorrect calculations (the very
> last number should be 2.5 and not 2).


In that case it did what it was instructed to do. The type was integer
so it converted.



Summming up: Observations show that SQLite3 behaves inconsistent when
> storing and/or calculating numbers as INTEGERs or REALs. The point I am
> personally worried about is not so much the storage side of things but the
> calculation errors resulting from it.


Since it behaves in predictable ways I don't believe inconsistency is
a big problem. Inconsistency is the only constant I've found in life!
It's only inconsistent on one operation, storing integers in a real
type. If you code with a rule of thumb to always insert
with something like "insert into t values( round(x) );" then you
will have no problems.


I would like to propose the resolve this inconsistency as follows:
>
>
That would make sqlite math inconsistent with math as performed
by computer languages. I don't see that as an improvement.


---
The Castles of Dereth Calendar: a tour of the art and architecture of
Asheron's Call
http://www.lulu.com/content/77264
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: the 3 numerical types (was Re: Problem/Bug: "SELECT 5 / 2;" returns 2 ?)

Jay Sprenkle
In reply to this post by Doug Currie-2
>
> For those still following this thread, and looking for more examples
> of the infinite representations of numbers ;-), here is another...
>
> Instead of a binary fixed point, you can use a binary number with an
> implicit decimal fixed point. For example, if your implicit decimal
> point were 10^2, the number 345 (stored as a binary integer) would
> represent the number 3.45. Concretely in C syntax, you'd print numbers
> as printf("%d.%02u", x/100, x%100). Addition and subtraction can be
> done with the integer operators. Multiplication and division take some
> care to avoid loss of range or precision, but abstractly, multiply is
> (x * y) / 100 and divide is (x * 100) / y. This is a neat hack to
> maintain fixed decimal accuracy with binary integers.
>
> > These values can also be stored as arbitrary precision integers,
> > which store multiple integers words to represent the value which can
> > again be interpreted as a fixed point fraction, or as BCD (binary
> > coded decimal) values which store 2 digits per byte.
>
> Storing numbers as *two* arbitrary precision integers, a numerator and
> a denominator, gives you all the exact rationals (at least as big as
> your memory allows -- reducing the numbers helps). Common Lisp and Scheme
> have rationals as well as real, complex, and arbitrary precision
> integer numbers. http://mathworld.wolfram.com/RationalNumber.html



There was also a proposed numbering system where the radix was
variable and was given by prime numbers. Pretty wild stuff but I've
never seen an implementation.
Reply | Threaded
Open this post in threaded view
|

Re: Problem/Bug: "SELECT 5 / 2;" returns 2 ?

Dennis Cote
In reply to this post by Ralf Junker
Ralf Junker wrote:

>>This can be fixed by checking the column affinity for a value when it is stored. If an integer value is being stored in a column with numeric affinity, then store the value as a REAL value rather than as an INTEGER value. This will perform the same conversion that the other engines do, and hence produce the same result when the division operation is performed later.
>>    
>>
>
>Unfortunately, this is not true for SQLite3. If you execute the following SQL commands
>
>  CREATE TABLE t (a REAL, b REAL);
>  INSERT INTO t VALUES (5, 2);
>
>both values are stored as INTEGER and not as REAL as one would expect by the column affinity. In fact, this behaviour is intentional and is stated in the help as a feature to minimize storage space for INTEGER numbers.
>
>  
>
I'm sorry I took so long to get back to, I started this reply last
night, but had to leave it unfinished until now.

To clarify what I said above (since it obviously wasn't clear).

The first thing to note is that SQLite applies a data type to individual
values, and data type affinities to table columns. These are different
things.

I meant that your division problem can be fixed in SQLite if SQLite is
modified so that it checks the affinity of the column before storing the
integer value. In SQLite a column declared as REAL has an affinity of
NUMERIC (see http://www.sqlite.org/datatype3.html section 2.1). The
problem is that currently columns with NUMERIC affinity can store values
of any type, in particular it can store both INTEGER and REAL (see
section 1 of the data types documentation). The required change would be
to modify SQLite so that it would convert INTEGER values to REAL values
when they are stored in a column with NUMERIC affinity.

This would make your division work as expected. The integer value
supplied to the insert statement would be converted to real and stored
as real in the table. When the select statement later retrieves the
values to do the division, it will have real values and do floating
point path to produce a real result.

It has some side effects that others may not like however. Storing a
value of 5 into the table would return a value of 5.0 when selected,
since SQLite (at least the newest versions) formats REAL values with a
decimal point on output. It would also make the database files larger if
they were storing integer values in a typeless column or one with a type
that produced NUMERIC affinity (again see the data types doc for the
rules).

If a user really wants to force values to be stored and returned as
integers they would simply need to explicitly declare the columns to
have an INT type, so they would be assigned an INTEGER affinity. Then no
conversion would be done when the values are stored. To me this seems
like an optimization for both speed and space that the user can trigger
by explicitly specifying the column's data type.

>To force storing numbers as REALs SQLite3 requires to use data binding or to rewrite the 2nd command above like this:
>
>  INSERT INTO t VALUES (5.0, 2.0);
>
>In other words, SQLite3 requires REALs to be explicitly written as such. Many users are certainly not aware of this requirement. They expect REALs to be stored as REALs just like other DB-engines do if a column is defined as such. However, SQLite3 behaves differently and this can
>
> * result in wrong calculations / different than intended.
> * lead to data errors when importing SQL scripts from other DBMS.
>
>On the other INTEGER side, SQLite3 again behaves differently:
>
>  CREATE TABLE i (a INTEGER, b INTEGER);
>  INSERT INTO i VALUES (5, 2);
>  INSERT INTO i VALUES (5.0, 2.0);
>
>Both INSERTs above store the numbers as INTEGERs, even those explicitly marked as REALs by adding the '.0' decimal.
>
>  
>
This behavior is also documented on the data type page. If the REAL
value can be represented exactly as an INTEGER, an INTEGER is stored in
columns declared to be of type INT. If not, the REAL value is stored.
This seems reasonable to me. It is in some ways the complement to the
change I proposed above.

If you do this in a standard SQL engine it will silently convert the 5.0
value to an exact value with implementation defined precision. Usually
not a problem for 5.0, but I suspect that 5.1 will probably come out of
the INTEGER column with the same value as 5.0 does. In SQLite, it will
store the 5.1 value as a REAL value even though it is in a column with
INTEGER affinity.

>Another problem shows when calculations are not performed on colums with type affinity but just on plain numbers like in
>
>  SELECT 5 / 2;
>
>What exactly is intended? From the findings above, both numbers might be seen as INTEGERs, but if '5.0' is interpreted as an INTEGER above, '5' might just as well be a REAL.
>
>Arguing from "common sense" I would prefer 5 / 2 to return 2.5 rather than 2. If the result cannot be represented with exact numeric, I would rather want it to be aproximate only. I can not overcome the feeling that exact numeric is sometimes simply wrong, especially with the whole family of financial calculations.
>
>
>  
>
This means what the user typed. Return 5 divided by 2. Each of the
literal values also has a type, in this case both are integer. The SQL
standard requires that division of two integer values should return an
exact result. Since integer is the only exact numeric type that SQLite
has, and the precision and scale of the resulting exact numeric type are
implementation defined in the standard, using an integer result (which
has a scale of 0 and precision of 9 for 32 bits) conforms to the standard.

I'm somewhat surprised that Oracle and mySQL both depart from the
standard here, and at the same time relieved to see that PostgreSQL
(which is generally regarded as the most standard conforming database
engine) does what the standard says. It is possible that the others are
using some other exact numeric result type to display the result, but I
suspect not.

It is unfortunate that the result value used for this discussion, 2.5,
has an exact representation in binary floating point. It makes it hard
to tell how the value is being represented. If we use 10/3 we get a
result that is not exactly representable in binary floating point (or
decimal for that matter), so it might be easier to see how the value is
represented. In SQLite we can use the typeof function to get the type of
the result.

select typeof(5/2);
integer

It would be interesting to see what type the other database engines
return if they have a similar facility.

In any case, I think that sqlite should continue to conform to the SQL
standard in this regard. I appreciate that many languages, like Python,
do this differently, but they are following a different standard.






 
Reply | Threaded
Open this post in threaded view
|

RE: Problem/Bug: "SELECT 5 / 2;" returns 2 ?

Fred Williams
Anybody thought of:

        t1.a = 5
        t1.b = 2

select a / (b * 1.0);

I think that would return a real.

-----Original Message-----
From: Dennis Cote [mailto:[hidden email]]
Sent: Friday, September 30, 2005 11:10 AM
To: [hidden email]
Subject: Re: [sqlite] Problem/Bug: "SELECT 5 / 2;" returns 2 ?


Ralf Junker wrote:

>>This can be fixed by checking the column affinity for a value when it
is stored. If an integer value is being stored in a column with numeric
affinity, then store the value as a REAL value

...


Reply | Threaded
Open this post in threaded view
|

Re: Problem/Bug: "SELECT 5 / 2;" returns 2 ?

Ralf Junker
In reply to this post by D. Richard Hipp
Hello DRH,

>> 3. If the division of INTEGERs can not be stored as an INTEGER
>>(i.e. if a % b != 0), the result should be returned as a REAL.
>>
>
>create table t1( a integer, b integer);
>insert into t1 values(5,2);
>update t1 set a=a/b;
>
>If your rule above was in force, this would leave
>T1.A holding 2.5, which is incompatible with the
>way other database engines work.

Well, understandable. But suppose that's exactly what one wants to do? How to achieve this using the current implementation of sqlite3?

On the other hand, I think that the following, currently implemented behaviour of sqlite3 is also incompatible with the way other database engines work. Where they return 2.5 for real type columns, sqlite3 does not:

  create table t1 (a real, b real);
  insert into t1 values (5,2);
  select a / b from t1;
  2

So the final question biols down to: How can I reliably guarantee a real type result for divisions on real typed columns even if they happen to contain integers? I cant't believe I always have to use a workaround like this:

  select 1.0 * a / b from t1;

I am sure there must be a better possibility without the extra multiplication! Or is there not?

Regards,

Ralf  

Reply | Threaded
Open this post in threaded view
|

RE: Problem/Bug: "SELECT 5 / 2;" returns 2 ?

Jackson, Douglas H
In reply to this post by Ralf Junker
Perhaps not a solution, but a workaround:
Try coercing the data entering the table into
a value recognizable as a real:

Create trigger t_t1i after insert on t1
Begin
  Update t1 set a = 1.0 * a, b = 1.0 * b
  Where rowid = new.rowid;
End;

Create trigger t_t1u after update on t1
Begin
   Update t1 set a = 1.0 * a, b = 1.0 * b
   Where rowid = new.rowid;
End;

The table will then hold reals in all cases.

Expressions then work without change:
  Select a/b from t1;
  Update a set a = a / b;

Doug

-----Original Message-----
From: Ralf Junker [mailto:[hidden email]]
Sent: Monday, October 03, 2005 7:12 AM
To: [hidden email]
Subject: Re: [sqlite] Problem/Bug: "SELECT 5 / 2;" returns 2 ?

Hello DRH,

>> 3. If the division of INTEGERs can not be stored as an INTEGER
>>(i.e. if a % b != 0), the result should be returned as a REAL.
>>
>
>create table t1( a integer, b integer);
>insert into t1 values(5,2);
>update t1 set a=a/b;
>
>If your rule above was in force, this would leave
>T1.A holding 2.5, which is incompatible with the
>way other database engines work.

Well, understandable. But suppose that's exactly what one wants to do?
How to achieve this using the current implementation of sqlite3?

On the other hand, I think that the following, currently implemented
behaviour of sqlite3 is also incompatible with the way other database
engines work. Where they return 2.5 for real type columns, sqlite3 does
not:

  create table t1 (a real, b real);
  insert into t1 values (5,2);
  select a / b from t1;
  2

So the final question biols down to: How can I reliably guarantee a real
type result for divisions on real typed columns even if they happen to
contain integers? I cant't believe I always have to use a workaround
like this:

  select 1.0 * a / b from t1;

I am sure there must be a better possibility without the extra
multiplication! Or is there not?

Regards,

Ralf  

Reply | Threaded
Open this post in threaded view
|

Re: Problem/Bug: "SELECT 5 / 2;" returns 2 ?

René Tegel
In reply to this post by Ralf Junker
Hi,

May i add to that that 'order by' also seems involved, see below. This
can lead to really unexpected errors... "order by 1.0 * b / c" as
workaround solves it btw.
Differating between floating point operator '/' and integer operator
'DIV' like some program languages do would lead to predictable output.

regards,

rene

=======================
#select *, b/c, 1.0 * b/c from test2 order by b/c
a b c b/c 1.0 * b/c
1 3 4 0 0.75
2 5 6 0 0.833333333333333
5 6 7 0 0.857142857142857
6 6 8 0 0.75
7 7 8 0 0.875
3 7 6 1 1.16666666666667
4 6 6 1 1.0
8 8 8 1 1.0
9 9 8 1 1.125
10 10 8 1 1.25
11 9 8 1 1.125
12 8 8 1 1.0
13 11 8 1 1.375
14 13 8 1 1.625
15 12 8 1 1.5

#select *, b/c, 1.0 * b/c from test2 order by 1.0*b/c
a b c b/c 1.0 * b/c
1 3 4 0 0.75
6 6 8 0 0.75
2 5 6 0 0.833333333333333
5 6 7 0 0.857142857142857
7 7 8 0 0.875
4 6 6 1 1.0
8 8 8 1 1.0
12 8 8 1 1.0
9 9 8 1 1.125
11 9 8 1 1.125
3 7 6 1 1.16666666666667
10 10 8 1 1.25
13 11 8 1 1.375
15 12 8 1 1.5
14 13 8 1 1.625




Ralf Junker wrote:

> Hello DRH,
>
>
>>>3. If the division of INTEGERs can not be stored as an INTEGER
>>>(i.e. if a % b != 0), the result should be returned as a REAL.
>>>
>>
>>create table t1( a integer, b integer);
>>insert into t1 values(5,2);
>>update t1 set a=a/b;
>>
>>If your rule above was in force, this would leave
>>T1.A holding 2.5, which is incompatible with the
>>way other database engines work.
>
>
> Well, understandable. But suppose that's exactly what one wants to do? How to achieve this using the current implementation of sqlite3?
>
> On the other hand, I think that the following, currently implemented behaviour of sqlite3 is also incompatible with the way other database engines work. Where they return 2.5 for real type columns, sqlite3 does not:
>
>   create table t1 (a real, b real);
>   insert into t1 values (5,2);
>   select a / b from t1;
>   2
>
> So the final question biols down to: How can I reliably guarantee a real type result for divisions on real typed columns even if they happen to contain integers? I cant't believe I always have to use a workaround like this:
>
>   select 1.0 * a / b from t1;
>
> I am sure there must be a better possibility without the extra multiplication! Or is there not?
>
> Regards,
>
> Ralf  
>

Reply | Threaded
Open this post in threaded view
|

Re: Problem/Bug: "SELECT 5 / 2;" returns 2 ?

Ralf Junker
Hello René Tegel,

>May i add to that that 'order by' also seems involved, see below. This can lead to really unexpected errors... "order by 1.0 * b / c" as workaround solves it btw.

Thanks for pointing this out.

I am sure we will be able to come up with even more examples where the confusion of INTEGER / REAL numbers leads to unexpected errors.

>Differating between floating point operator '/' and integer operator 'DIV' like some program languages do would lead to predictable output.

Surely one possible solutions, but it very likely does not conform to the SQL standard (but I haven't checked). On the other hand, the sqlite3 column affinity does not result in standard output either for the examples given in this thread.

Is there any chance that the problem will be addressed in the forseable future? Do we need to create a ticket to put it on the agenda?

Regards,

Ralf

Reply | Threaded
Open this post in threaded view
|

Re: Problem/Bug: "SELECT 5 / 2;" returns 2 ?

René Tegel
Hi,

Richard, I like to ask you, just to make sure; has the `order by`
"bug"/issue, as result from automatic float->int conversion, been
considered by you and if yes, do you plan any changes?

regards,

rene

Ralf Junker wrote:

> Hello Ren? Tegel,
>
>
>>May i add to that that 'order by' also seems involved, see below. This can lead to really unexpected errors... "order by 1.0 * b / c" as workaround solves it btw.
>
>
> Thanks for pointing this out.
>
> I am sure we will be able to come up with even more examples where the confusion of INTEGER / REAL numbers leads to unexpected errors.
>
>
>>Differating between floating point operator '/' and integer operator 'DIV' like some program languages do would lead to predictable output.
>
>
> Surely one possible solutions, but it very likely does not conform to the SQL standard (but I haven't checked). On the other hand, the sqlite3 column affinity does not result in standard output either for the examples given in this thread.
>
> Is there any chance that the problem will be addressed in the forseable future? Do we need to create a ticket to put it on the agenda?
>
> Regards,
>
> Ralf
>

Reply | Threaded
Open this post in threaded view
|

Re: Problem/Bug: "SELECT 5 / 2;" returns 2 ?

D. Richard Hipp
In reply to this post by Ralf Junker
=?ISO-8859-1?Q?Ren=E9_Tegel?= <[hidden email]> wrote:
> Hi,
>
> Richard, I like to ask you, just to make sure; has the `order by`
> "bug"/issue, as result from automatic float->int conversion, been
> considered by you and if yes, do you plan any changes?
>

I have made note of the issues raised. I do not have a
solution to the problem at this point. (The various solutions
proposed on this mailing list are all unacceptable for
various reasons.)

You have a simple workaround:  Just add 0.0 to anything
that you definitely want to be floating point.

I will continue to trying to figure out a reasonable method
of addressing your concerns.

--
D. Richard Hipp <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

RE: Problem/Bug: "SELECT 5 / 2;" returns 2 ?

Clark, Chris M
In reply to this post by Ralf Junker

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Thu 10/6/2005 10:14 AM
> Subject: Re: [sqlite] Problem/Bug: "SELECT 5 / 2;" returns 2
> <[hidden email]> wrote:
> > Richard, I like to ask you, just to make sure; has the `order by`
> > "bug"/issue, as result from automatic float->int conversion, been
> > considered by you and if yes, do you plan any changes?
> >
>
>
> You have a simple workaround:  Just add 0.0 to anything
> that you definitely want to be floating point.
>
> I will continue to trying to figure out a reasonable method
> of addressing your concerns.
In other databases the behavior in sqlite is the expected behavior. E.g. IBM db2udb, Ingres, Microsoft SQL Server. Oracle is different because of the wierd NUMBER datatype which is used to store both ints and decimal - I don't know about any others.

In most databases the datatypes of the operands dictate the result type; which  is the sqlite behavior.

Chris


Reply | Threaded
Open this post in threaded view
|

RE: Problem/Bug: "SELECT 5 / 2;" returns 2 ?

Preston Zaugg
In reply to this post by Ralf Junker
I haven't tried this myself.. but there is another possible solution. The
sqlite documentation describes that there are 3 affinity modes. One of these
modes is "Strict affinity mode". It appears to me that an "int" pushed into
a column of type "real" would be coerced into a real and would behave as the
author of the original post intended.

ofcourse as the title of this post suggests select 5/2 would still return 2.
But, a table with a 5 and a 2 stored in them, that was declared as real,
would yield the intended result of 2.5.

here is the reference i referred to: http://www.sqlite.org/datatype3.html 
(bullet point #6)

I don't know if this is a database setting or a compile time setting or
what...(i would hope database setting) it might be worth trying out.

--Preston

 > -----Original Message-----
 > From: [hidden email] [mailto:[hidden email]]
 > Sent: Thu 10/6/2005 10:14 AM
 > Subject: Re: [sqlite] Problem/Bug: "SELECT 5 / 2;" returns 2
 > <[hidden email]> wrote:
 > > Richard, I like to ask you, just to make sure; has the `order by`
 > > "bug"/issue, as result from automatic float->int conversion, been
 > > considered by you and if yes, do you plan any changes?
 > >
 >
 >
 > You have a simple workaround:  Just add 0.0 to anything
 > that you definitely want to be floating point.
 >
 > I will continue to trying to figure out a reasonable method
 > of addressing your concerns.

In other databases the behavior in sqlite is the expected behavior. E.g. IBM
db2udb, Ingres, Microsoft SQL Server. Oracle is different because of the
wierd NUMBER datatype which is used to store both ints and decimal - I don't
know about any others.

In most databases the datatypes of the operands dictate the result type;
which  is the sqlite behavior.

Chris


Reply | Threaded
Open this post in threaded view
|

Please Need Advice on 64 Bits Platform

Hamid Benhocine
Hi all,

I am always on the lookout for simple yet powerful software development
tools  and SQLite definitely falls into this category.
It is a very great software. I tested the software a lot to replace our
home data format (for Meteroligical Observations). The engine
is very very fast for insertion of millions of records of satellite
data. All the job was carried on Linux, SGI IRIX64 (front ends) The software
was compiled in 32 bits mode. I did also some tests  on our
SuperComputer  IBM (Aix v 5.1) and SQlite work great when Compiled in 32
b mode
(-q32 -qlonglong  VisualAge xlc flags etc).
Because every peace of software we use on IBM must compile in 64 bits
mode, ( I did not succeed to run Sqlite When Compiled iin 64 bits mode
And I'm not a Sofware Engeneer)  I want just to know if the Engine is 64
bits ready (the boss langage) or  Can we call Sqlite (Complied 32 bits) from
64 bits applications. Any advice is Welcome. I worked very hard to push
Sqlite to replace our home data format (Sqlite will do Solve a lot
of  our pbs .)
Thanks A lot.
Hamid


Reply | Threaded
Open this post in threaded view
|

Re: Please Need Advice on 64 Bits Platform

D. Richard Hipp
Hamid Benhocine <[hidden email]> wrote:
> I want just to know if the Engine is 64
> bits ready

SQLite is designed to work on 64-bit machines.  There
have been a few alignment problems in the past but those
have all been worked out now, I believe.  I do not have
a 64-bit machine to test on, but reports from users are
that SQLite works when compiled in 64-bit mode.
--
D. Richard Hipp <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: Please Need Advice on 64 Bits Platform

Robert L Cochran
I have an AMD 64 machine myself. Do I need to pass any special to
compile in 64 bit mode?

Bob

[hidden email] wrote:

>Hamid Benhocine <[hidden email]> wrote:
>  
>
>>I want just to know if the Engine is 64
>>bits ready
>>    
>>
>
>SQLite is designed to work on 64-bit machines.  There
>have been a few alignment problems in the past but those
>have all been worked out now, I believe.  I do not have
>a 64-bit machine to test on, but reports from users are
>that SQLite works when compiled in 64-bit mode.
>--
>D. Richard Hipp <[hidden email]>
>
>
>
>  
>

Reply | Threaded
Open this post in threaded view
|

Re: Please Need Advice on 64 Bits Platform

Jarosław Nozderko
In reply to this post by Hamid Benhocine
I've just built SQLite 3.2.7 on HP-UX 11 in 64-bit mode.
Loading 1000 000 records into a simple table (using .read
from SQL script with inserts, 10000 in a single transaction)
took 5 min 40 s (the same in 32-bit - 06:29) and creating
index 56 s (01:14 for 32-bit). Unfortunately, this is
heavily loaded server, so results above may not be precise.


Regards,
Jarek

> Hamid Benhocine <[hidden email]> wrote:
> > I want just to know if the Engine is 64 bits ready
>
> SQLite is designed to work on 64-bit machines.  There have
> been a few alignment problems in the past but those have all
> been worked out now, I believe.  I do not have a 64-bit
> machine to test on, but reports from users are that SQLite
> works when compiled in 64-bit mode.
> --
> D. Richard Hipp <[hidden email]>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Please Need Advice on 64 Bits Platform

Hamid Benhocine
Hi,
IBM : powerpc-ibm-aix5.1.0.0
I did a lot of cleanup in environnemnts variables.
then
1 ) export OBJECT_MODE=64
2) I stick with a simple configure
./../sqlite-3.2.7/configure --disable--shared --disable-tcl
--disable-threadsafe --prefix=$PREFIX
3) in the Makefile  put
-q64 -qlonglong for the xlc compiler
4) in ./libtool forced ar with -X64 flag

results: SQLite Works fine . I did some basics tests  (inserts,simple
selects, create temp tables ..)
I think , Now people here, will certainly consider this very great
Engine to suit there needs.. and
replace the ..... home data format.

Thansks all and thanks drh.

I will post if i have trouble.

Hamid.

 


Jaros?aw Nozderko wrote:

>I've just built SQLite 3.2.7 on HP-UX 11 in 64-bit mode.
>Loading 1000 000 records into a simple table (using .read
>from SQL script with inserts, 10000 in a single transaction)
>took 5 min 40 s (the same in 32-bit - 06:29) and creating
>index 56 s (01:14 for 32-bit). Unfortunately, this is
>heavily loaded server, so results above may not be precise.
>
>
>Regards,
>Jarek
>
>  
>
>>Hamid Benhocine <[hidden email]> wrote:
>>    
>>
>>>I want just to know if the Engine is 64 bits ready
>>>      
>>>
>>SQLite is designed to work on 64-bit machines.  There have
>>been a few alignment problems in the past but those have all
>>been worked out now, I believe.  I do not have a 64-bit
>>machine to test on, but reports from users are that SQLite
>>works when compiled in 64-bit mode.
>>--
>>D. Richard Hipp <[hidden email]>
>>
>>    
>>
>
>
>  
>

Reply | Threaded
Open this post in threaded view
|

getting table size

Eno Thereska
In reply to this post by Dennis Cote
Hi,

Is there a SQL query that returns the size in bytes a table occupies?

Thanks
Eno

12