Типы полей и скорострельность
Типы полей и скорострельность
Вопрос опытным (все что ниже ИМХО, прошу поправить, для этого и пишу сюда)
Насколько знаю "внутри проца" в 32-разрядных системах происходит выравнивание переменных до 32 бит (ИМХО). По крайней мере два одинаковых алгоритма, которые экономят память используя переменные ShortInt, Byte, Char и Boolean работают медленнее чем соответственно Integer,Integer,Integer и Integer. Причем это сам обнаруживал на практике - Integer быстрее, чем замена его на ShortInt или Word.
Собственно вопрос: использование в таблице FB/IB полей ShortInt, Char(1) вместо соответственно Integer, Integer приведет к экономии размера БД, но и уменьшению производительности - это верно? Имеются ввиду базы в десятки гигабайт, причем производительность приоритетна и если использование Integer вместо Char(1) приведет хотя бы к 1% увеличения производительности - для меня это серьезная причина не экономить дисковое пространство.
Насколько знаю "внутри проца" в 32-разрядных системах происходит выравнивание переменных до 32 бит (ИМХО). По крайней мере два одинаковых алгоритма, которые экономят память используя переменные ShortInt, Byte, Char и Boolean работают медленнее чем соответственно Integer,Integer,Integer и Integer. Причем это сам обнаруживал на практике - Integer быстрее, чем замена его на ShortInt или Word.
Собственно вопрос: использование в таблице FB/IB полей ShortInt, Char(1) вместо соответственно Integer, Integer приведет к экономии размера БД, но и уменьшению производительности - это верно? Имеются ввиду базы в десятки гигабайт, причем производительность приоритетна и если использование Integer вместо Char(1) приведет хотя бы к 1% увеличения производительности - для меня это серьезная причина не экономить дисковое пространство.
Это ж легко самому проверить.
Я вот только что на 2.1 на Core2Duo E6420 2Gb RAM 160 HDD 7200 WD проверил, на 10 млн. записях:
Я вот только что на 2.1 на Core2Duo E6420 2Gb RAM 160 HDD 7200 WD проверил, на 10 млн. записях:
Замечу только, что сравнение C1 с целочисленным значением выдавало план NATURAL. Остальное и так видно.IBExpert писал(а):SELECT COUNT(C1) FROM TT WHERE C1 = 0
15.20
SELECT COUNT(C1) FROM TT WHERE C1 = '0'
2.30
SELECT COUNT(I) FROM TT WHERE I = 0
2.05
SELECT COUNT(S) FROM TT WHERE S = 0
2.11
SELECT C1, COUNT(C1) FROM TT GROUP BY C1 ORDER BY C1
33.10
SELECT I, COUNT(I) FROM TT GROUP BY I ORDER BY I
28.44
SELECT S, COUNT(S) FROM TT GROUP BY S ORDER BY S
27.50
SELECT COUNT(C1) FROM TT WHERE C1 = 0 OR C1 = 1
21.79
SELECT COUNT(C1) FROM TT WHERE C1 = '0' OR C1 = '1'
4.35
SELECT COUNT(I) FROM TT WHERE I = 0 OR I = 1
3.58
SELECT COUNT(S) FROM TT WHERE S = 0 OR S = 1
3.58
Хм. Т.е. я был прав. Из выводов в статье "2. Разницы в объеме занимаемых данных между char(1), integer и smallint нет как для таблиц, так и для индексов." - смысла нет делать SmallInt или Char(1) - объем БД не изменится. А вот скорострельность, и внутри птички и в алгоритмах на стороне клиента будет быстрее при использовании 32-х разрядных переменных на, соответственно, 32-х разрядных системах.
WildSery спасиба.
ps Интересно, для 64-х разрядных систем будет тоже самое?
WildSery спасиба.
ps Интересно, для 64-х разрядных систем будет тоже самое?