Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2006.09.24;
Скачать: CL | DM;

Вниз

Скорость работы запроса, и количество полей в таблице   Найти похожие ветки 

 
partizan   (2006-07-26 12:08) [0]

Влияет-ли на скорость запроса количество полей в таблице.
То-есть если в запросе учавствуют только 5 полей, но в таблице есть еще куча, не замедляет-ли это запрос?

Может имеет смысл те поля, которые редко учавствуют в запросе вынести в отдельную таблицу и join-ить ее по мере надобности?

(работаю с postgre)


 
ЮЮ ©   (2006-07-26 12:11) [1]

Если
 SELECT *
то естественно влияет

Если
 Select f1, f2, f3, f4, f5

и среди них нет BLOB-ов, то, скорей всего, - нет


 
Max Zyuzin ©   (2006-07-26 12:12) [2]

>partizan   (26.07.06 12:08)
Имеет смысл нормализовать таблицы и настроить индексы, а не выносить все подряд


 
partizan   (2006-07-26 12:17) [3]


> и среди них нет BLOB-ов, то, скорей всего, - нет


А чем принципиально отлючаются поля с BLOB-ами от обычных? Большим размером?

Просто постгре, при выполнении запроса подгружает часть таблицы в ОП, просматривает ее, затем подгружает следующий блок и т.д.
Получаятся чем меньше размер одной строки - тем больше строк за 1 раз можно загрузить в ОП за 1 раз


 
ЮЮ ©   (2006-07-26 12:24) [4]


> подгружает часть таблицы в ОП, просматривает ее,


И чего он та ищет? Может индексы по полям, участвующим в WHERE (если она в твоем запросе есть), лучше создать, чтобы она меньше там всего просматривала?


 
Desdechado ©   (2006-07-26 12:27) [5]

Не там проблемы ищешь. Нормализуйся и схему данных нормализуй.


 
partizan   (2006-07-26 12:31) [6]

Да есть индексы, и нормализовано. Но в таблице МНОГО записей


 
partizan   (2006-07-26 12:34) [7]

Я же не написал "У меня очень долго работает запрос - помогите". Я задал конкретный вопрос


 
Desdechado ©   (2006-07-26 12:38) [8]

Конкретный вопрос про то, как конкретный сервер обрабатывает конкретные таблицы, можно узнать у производителя сервера или (если открыты исходники) посмотреть там, а не гадать на гуще "читаем блок-забываем блок".


 
ЮЮ ©   (2006-07-26 12:39) [9]

Если в таблице много записей и вопрос выполнтся быстро, откуда такой философский вопрос? :)


 
partizan   (2006-07-26 12:45) [10]

Нужно еще быстрее


 
partizan   (2006-07-26 15:12) [11]

Проверил на практике (posgreSQL)
В 1-й тадлице было 6 полей, во 2-й 31, все инт4, количество записей - одинаковое.

Запрос SELECT count(id) FROM ... выполняется для 2-й таблице на 66% дольше


 
Desdechado ©   (2006-07-26 15:19) [12]

судя по ID - это PK
нормальный сервер в случае COUNT использует индекс по этому PK, не читая таблиц


 
Sergey13 ©   (2006-07-26 15:23) [13]

Чем шире таблица, тем меньше записей помещается в блоке данных на диске. Сервер читает блоками, а не полями. Следовательно, чем шире таблица, тем большее количество операций чтения надо сделать.
Это рассуждения "вообще", а не конкретно по постгре (не юзал).


 
Desdechado ©   (2006-07-26 15:42) [14]

Sergey13 ©   (26.07.06 15:23) [13]
> Чем шире таблица
Это верно. Но также верно и то, что чем шире таблица, тем меньше полей в ней имеют атрибут NOT NULL. А NULL-значения не хранятся, т.е. места не занимают.


 
Sergey13 ©   (2006-07-26 15:47) [15]

2 [14] Desdechado ©   (26.07.06 15:42)
> Это верно. Но также верно и то, что чем шире таблица, тем
> меньше полей в ней имеют атрибут NOT NULL.

С чего бы это? Тут никакой зависимости нет. И в 5 полях 4 могут быть нулами, и в 100 могут быть все нот нулл. Это как повезет.


 
Desdechado ©   (2006-07-26 15:53) [16]

> Тут никакой зависимости нет
Есть :)
В нормализованных таблицах эта закономерность хорошо прослеживается.
Понятно, что есть и отклонения от нее, но они только подтверждают зависимость.


 
Sergey13 ©   (2006-07-26 16:14) [17]

> [16] Desdechado ©   (26.07.06 15:53)

Выходя на проезжую часть мы всегда ждем автомобиля слева, забывая, что есть  дороги с односторониим движением. 8-)


 
Desdechado ©   (2006-07-26 16:23) [18]


>  забывая, что есть  дороги с односторониим движением
Но помятуя о том, что безбашенных на мотоциклах много, которых гоняют против движения :)



Страницы: 1 вся ветка

Текущий архив: 2006.09.24;
Скачать: CL | DM;

Наверх




Память: 0.51 MB
Время: 0.028 c
3-1153319574
barakuda
2006-07-19 18:32
2006.09.24
как ускорить процедуру


2-1157466033
DeMiUrG
2006-09-05 18:20
2006.09.24
ошибка при работе с Excel


10-1123433445
Nick Denry
2005-08-07 20:50
2006.09.24
Все тот же ActiveX....


2-1157620743
fly_mer
2006-09-07 13:19
2006.09.24
Тип TRecord и его копирование...


6-1146596297
Evereve
2006-05-02 22:58
2006.09.24
блокировать соединение с Интернетом