Sent: Friday, October 27, 2006 2:10 AM
> To: 'Jerry Schwartz'; mysql@lists.mysql.com
> Subject: RE: Speed of DECIMAL
>
> > From: Jerry Schwartz [mailto:[EMAIL PROTECTED]
> >
> > What is going slower, INSERT / UPDATES or SELECTS?
>
> Complex SELECTs
>
>
I'll second what Chris said, which is that all the joined columns
should be of the same type for speed.
Also, your substring and LIKE comparisons are going to be problematic,
as those are string operations, not numeric, and MySQL is having to
convert all the decimal values to strings before compa
[EMAIL PROTECTED] wrote:
From: Jerry Schwartz [mailto:[EMAIL PROTECTED]
What is going slower, INSERT / UPDATES or SELECTS?
Complex SELECTs
CHAR should make for quite efficient processing, since to a
large degree nobody cares what's in there: it just slams the
data in, or does a simple byte
> From: Jerry Schwartz [mailto:[EMAIL PROTECTED]
>
> What is going slower, INSERT / UPDATES or SELECTS?
Complex SELECTs
> CHAR should make for quite efficient processing, since to a
> large degree nobody cares what's in there: it just slams the
> data in, or does a simple byte-by-byte compari
What is going slower, INSERT / UPDATES or SELECTS?
CHAR should make for quite efficient processing, since to a large degree
nobody cares what's in there: it just slams the data in, or does a simple
byte-by-byte comparison. There is probably hardware support for that kind of
operation. Decimal arit
Did you leave your queries searching on ASCII instead of decimal? Depending on how you structured your queries, MySQL may actually
be converting the fields to ASCII in order to do the comparison. Which would probably take 3x longer since it's not using an index.
- Original Message -
Fro
