Re: Using INTEGER instead of VARCHAR/DATE - is this a way to faster access?

2014-11-06 21:49 GMT+01:00, Roberta Jaskólski : > Ugh--I missed the discussion shift from the DATEs to the VARCHAR labels ... > and now I wholeheartedly agree with you. > > As for the DATEs, I yet suspect that for performance maybe TIMESTAMP is > slightly better than DATE. Well what I'm interest

Re: Using INTEGER instead of VARCHAR/DATE - is this a way to faster access?

2014/11/04 11:04 -0800, Jan Steinman I was not suggesting it for dates. The OP appeared to have a well-defined set of strings in a VARCHAR field — THAT is what I suggested ENUMs for! What is the update frequency of those VARCHARs? If you're adding them often — or if you need to

Re: Using INTEGER instead of VARCHAR/DATE - is this a way to faster access?

> From: (Halász Sándor) h...@tbbs.net > > 2014/10/29 20:56 +0100, Zbigniew > if instead of textual labels I'll use SMALLINT as simple integer "code" for > each different "label" (and in my program a translation table)? > > This, in effect, is ENUM... Well, not really! With I

Re: Using INTEGER instead of VARCHAR/DATE - is this a way to faster access?

- Original Message - > From: "Zbigniew" > Subject: Using INTEGER instead of VARCHAR/DATE - is this a way to faster > access? >> What about using ENUMs? They have nearly the performance of INTEGERs, but >> you don't have to maintain a string mapping

Re: Using INTEGER instead of VARCHAR/DATE - is this a way to faster access?

2014/11/02 13:19 +0100, Zbigniew So you guys (Jan and "hsv") suggest, that switching from DATE to "more numeric" data type may not be necessary, but using ENUM instead of VARCHAR can be real performance gain, right? But are you able to estimate, what "boost" can i notice? 5% - or 50%, or

Re: Using INTEGER instead of VARCHAR/DATE - is this a way to faster access?

> From: Zbigniew > >> switching from DATE to "more numeric" data type may not be necessary... I would hope that the query optimizer converts '2014-11-02' to the three-bytes internal representation of DATE before doing the query, in which case, DATE should actually be a tiny bit faster than TIM

Re: Using INTEGER instead of VARCHAR/DATE - is this a way to faster access?

2014-10-31 5:29 GMT+01:00, Jan Steinman : > What about using ENUMs? They have nearly the performance of INTEGERs, but > you don't have to maintain a string mapping in your programming logic. So you guys (Jan and "hsv") suggest, that switching from DATE to "more numeric" data type may not be neces

Re: Using INTEGER instead of VARCHAR/DATE - is this a way to faster access?

> From: Zbigniew > > Now to the point: considering, that the second column shall contain > about 100-200 different "labels" - so in average many of such labels > can be repeated one million times (or even more) What about using ENUMs? They have nearly the performance of INTEGERs, but you don't

Re: Using INTEGER instead of VARCHAR/DATE - is this a way to faster access?

> From: Zbigniew > > Now to the point: considering, that the second column shall contain > about 100-200 different "labels" - so in average many of such labels > can be repeated one million times (or even more) What about using ENUMs? They have essentially the performance of INTEGERs, but you

Re: Using INTEGER instead of VARCHAR/DATE - is this a way to faster access?

2014/10/29 20:56 +0100, Zbigniew Now to the point: considering, that the second column shall contain about 100-200 different "labels" - so in average many of such labels can be repeated one million times (or even more) - will it speed-up the selection done with something like "...WHERE la

Using INTEGER instead of VARCHAR/DATE - is this a way to faster access?

I'm going to establish a large database (ISAM) of simple structure, say the table with only 3 columns: - VARCHAR(80) - VARCHAR(40) - DATE The number of rows can be quite large, about hundred million or so. The first column, containing actual information, will contain unique values, unlike the two