ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / что выгоднее с точки зрения быстродейсвия поиска данных - бить индексы или бить таблицы?
7 сообщений из 7, страница 1 из 1
что выгоднее с точки зрения быстродейсвия поиска данных - бить индексы или бить таблицы?
    #34774148
untitled
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
untitled
Участник
допустим есть таблица table с полями key и secondary_key
возможных значений поля secondary_key на несколько порядков меньше чем значений key

требуется увеличить скорость запроса вида
Код: plaintext
1.
select * from table where key = X and secondary_key=Y




что лучше, разбить таблицу партиционированием в зависимости от значения secondary_key на много маленьких таблиц, или оставить одну таблицу но создать много индексов по типу:
Код: plaintext
1.
CREATE  INDEX ind_x ON table (key) WITH (secondary_key = x);


сложность заключается в том, что на эту таблицу ссылается foreign key, и если разбить таблицу, то foreign key придется удалить, что не есть хорошо, если бить индексы, то такой проблемы нет, но тогда встает вопрос - даст ли разбиение индекса схожий прирост производительности?
...
Рейтинг: 0 / 0
04.09.2007, 12:49
| Ответить | Цитировать | Написать  
что выгоднее с точки зрения быстродейсвия поиска данных - бить индексы или бить таблицы?
    #34774255
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
untitledвозможных значений поля secondary_key на несколько порядков меньше чем значений key

where key = X and secondary_key=Yоставить одну таблицу, создать индекс (key,secondary_key)
...
Рейтинг: 0 / 0
04.09.2007, 13:11
| Ответить | Цитировать | Написать  
что выгоднее с точки зрения быстродейсвия поиска данных - бить индексы или бить таблицы?
    #34774291
untitled
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
untitled
Участник
LeXa NalBatоставить одну таблицу, создать индекс (key,secondary_key)

это конечно же было сделано в первую очередь, но этого оказалось недостаточно
при текущем размере таблицы с таким индексом поиск происходит ~1000ms, а это чертовски долго
хотелось добиться хотя бы ~100 ms
...
Рейтинг: 0 / 0
04.09.2007, 13:19
| Ответить | Цитировать | Написать  
что выгоднее с точки зрения быстродейсвия поиска данных - бить индексы или бить таблицы?
    #34774348
assa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
assa
Участник
untitled LeXa NalBatоставить одну таблицу, создать индекс (key,secondary_key)

это конечно же было сделано в первую очередь, но этого оказалось недостаточно
при текущем размере таблицы с таким индексом поиск происходит ~1000ms, а это чертовски долго
хотелось добиться хотя бы ~100 msесли теория не врет - время индексного поиска растет логарифмически. Набрать больше порядка на логарифме - вещь довольно сильная.

Правда, есть вероятность что
1. у вас на деле не ключевой индекс, и вы выбираете кучу записей. И основные затраты - на чтение этой кучи записей.
2. что (в силу особливости индекса в пг) у вас не слишком актуален индекс. и вам надо чаще делать реиндекс.


3. вот насчет времени на чтение собственно индекса (и какую его порцию нужно читать на поиск еденичной записи) - сообразить не могу.
...
Рейтинг: 0 / 0
04.09.2007, 13:32
| Ответить | Цитировать | Написать  
что выгоднее с точки зрения быстродейсвия поиска данных - бить индексы или бить таблицы?
    #34774470
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
untitledпри текущем размере таблицы с таким индексом поиск происходит ~1000msпокажите explain analyze
...
Рейтинг: 0 / 0
04.09.2007, 13:58
| Ответить | Цитировать | Написать  
что выгоднее с точки зрения быстродейсвия поиска данных - бить индексы или бить таблицы?
    #34775506
untitled
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
untitled
Участник
assa
Правда, есть вероятность что
1. у вас на деле не ключевой индекс, и вы выбираете кучу записей. И основные затраты - на чтение этой кучи записей.


я забыл сказать. да, это не ключевой индекс. но результат в ~1000ms - это для запроса, возвращающего одно значение


LeXa NalBatпокажите explain analyze
например такой

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
explain analyze select * from values where uv_id =  23324  and kt_id= 42 

Bitmap Heap Scan on "values"  (cost= 12 . 78 .. 4440 . 01  rows= 1130  width= 68 ) (actual time= 0 . 335 .. 0 . 338  rows= 1  loops= 1 )
  Recheck Cond: ((uv_id =  23324 ) AND (kt_id =  42 ))
  ->  Bitmap Index Scan on i_uv_kt_values  (cost= 0 . 00 .. 12 . 78  rows= 1130  width= 0 ) (actual time= 0 . 304 .. 0 . 304  rows= 1  loops= 1 )
        Index Cond: ((uv_id =  23324 ) AND (kt_id =  42 ))
Total runtime:  0 . 851  ms

либо такой

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
explain analyze select * from values where uv_id =  149953  and  kt_id= 5 

Index Scan using i_uv_kt_values on "values"  (cost= 0 . 00 .. 130 . 43  rows= 32  width= 68 ) (actual time= 0 . 322 .. 45 . 261  rows= 1308  loops= 1 )"
  Index Cond: ((uv_id =  149953 ) AND (kt_id =  5 ))
Total runtime:  73 . 458  ms

когда записей много все совсем печально
...
Рейтинг: 0 / 0
04.09.2007, 17:48
| Ответить | Цитировать | Написать  
что выгоднее с точки зрения быстродейсвия поиска данных - бить индексы или бить таблицы?
    #34776393
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
untitled
Код: plaintext
Total runtime:  0 . 851  ms
Это одна миллисекунда, а не 851.
...
Рейтинг: 0 / 0
05.09.2007, 09:38
| Ответить | Цитировать | Написать  
7 сообщений из 7, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / что выгоднее с точки зрения быстродейсвия поиска данных - бить индексы или бить таблицы?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]