Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
увеличение производительности разделением таблицы
|
|||
|---|---|---|---|
|
#18+
Подскажите советом. Допустим есть некая таблица. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. В селектах используются только первые два поля, т.е. id и file_name Таблица еще имеет достаточно большое количество полей с разными атрибутами, которые используются редко, но нужны для каждой записи. Теперь вопрос. Если разделить записи на две таблицы. В первой храним только первые два поля, которые используются для частых селектов, во-второй, все остальное с привязкой по id на первую таблицу. Даст ли такой метод уменьшение времени для селектов? Что еще можете посоветовать? Попробовал использовать Inheritance, это только увеличило время, за счет обращения к таблице-наследнику. Или для PG вообще не важно, сколько полей имеет таблица? Конечная цель, получить наименьшее время при селектах для первых двух полей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2006, 12:36 |
|
||
|
увеличение производительности разделением таблицы
|
|||
|---|---|---|---|
|
#18+
А запросы-то какие? (примерчик плиз) Ведь в разных ситуациях по разному. Но если записи апдейтятся редко, и запрос использует индекс, то, думаю, в одной таблице много лучше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2006, 18:31 |
|
||
|
увеличение производительности разделением таблицы
|
|||
|---|---|---|---|
|
#18+
А я думаю - наоборот. Если постоянно извлекается пару основных полей, то постгрес вполне может закешировать всю таблицу, в случае же если таблица большая - в кеш попадет только часть... Лучше всего тест написать и проверить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2006, 19:37 |
|
||
|
увеличение производительности разделением таблицы
|
|||
|---|---|---|---|
|
#18+
запрос выглядит примерно так Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. таблица имеет до 10000 записей. думаю, что еще над самим селектом можно поработать, оптимизировать. добавлю к первоначальному своему вопросу следующее: есть поля которые селектятся все время. есть которые почти не селектятся. есть которые апдейтятся. исходя из этого думаю разделить их на 3 таблицы соответсвенно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2006, 00:02 |
|
||
|
увеличение производительности разделением таблицы
|
|||
|---|---|---|---|
|
#18+
HordiА я думаю - наоборот. Если постоянно извлекается пару основных полей, то постгрес вполне может закешировать всю таблицу, в случае же если таблица большая - в кеш попадет только часть... Лучше всего тест написать и проверить. Если извлекаемые данные целиком содержатся в индексе, то Oracle (и IMHO MS SQL) способен не лазить в саму таблицу вообще. Если PostgreSQL ведет себя так же, то задача сводится к правильному выбору индексов над таблицей, т.е. м.б. полезно включить в индекс поле, которое выбирают, но которое не используется для поиска. Не совсем понятно, почему автор решил скрыть от общественности, какие индексы помимо primary key использованы. Именно это и представляет наибольший интерес. Если честно, проблема кажется надуманной: поиск записи по индексу должен очень слабо зависеть от колонок, которые не входят в индекс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2006, 10:55 |
|
||
|
увеличение производительности разделением таблицы
|
|||
|---|---|---|---|
|
#18+
2ilejn: Поддерживаю. При поиске по индексу разница при выборке из полной таблицы или усеченной - копейки... Но протестить конкретную реализацию не помешало бы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2006, 11:45 |
|
||
|
увеличение производительности разделением таблицы
|
|||
|---|---|---|---|
|
#18+
Про индексы "ничего не сказал" без злого умыслу :) Индекс используется обычный на поле file_name типа btree. Хорошо, если при селектах нет существенной разницы одна или две таблицы, и он все что надо берет в индексах. А если в строке есть поле счетчика которое часто меняется? Не приводит это к разбуханию таблицы и лишним тормозам на автовакуме? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2006, 16:33 |
|
||
|
увеличение производительности разделением таблицы
|
|||
|---|---|---|---|
|
#18+
DeWiL А если в строке есть поле счетчика которое часто меняется? Не приводит это к разбуханию таблицы и лишним тормозам на автовакуме? Если размер счетчика не изменяется (он ведь у тебя не VARHCAR, правда?) и по нему нет индекса, то, исходя изо всех возможных рациональных соображений, описанных проблем быть не должно. PostgreSQL и рациональные соображения крайне редко входят в противоречия друг с другом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2006, 17:30 |
|
||
|
увеличение производительности разделением таблицы
|
|||
|---|---|---|---|
|
#18+
> таблица имеет до 10000 записей Смешной объем. Не парьтесь. Была бы табличка на три порядка больше - можно было бы думать об оптимизации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2006, 18:12 |
|
||
|
увеличение производительности разделением таблицы
|
|||
|---|---|---|---|
|
#18+
DeWiLзапрос выглядит примерно так ... думаю, что еще над самим селектом можно поработать, оптимизировать.Наверное сначала надо попытаться оптимизировать запрос - это может дать гораздо большую пользу, чем разделение таблицы. Киньте explain analyze запроса, который вы привели. ilejnЕсли извлекаемые данные целиком содержатся в индексе, то Oracle (и IMHO MS SQL) способен не лазить в саму таблицу вообще. Если PostgreSQL ведет себя так же,Постгрес ведет себя иначе - все равно заглядывает в таблицу. Это объясняется используемой транзакционной моделью, досконально обяснить не могу, потому что не уверен в собственном понимании. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 08:56 |
|
||
|
увеличение производительности разделением таблицы
|
|||
|---|---|---|---|
|
#18+
ilejnЕсли размер счетчика не изменяется (он ведь у тебя не VARHCAR, правда?) и по нему нет индекса Зато есть другие индексы, и они то и будут расти при каждом апдейте счетчика ilejnPostgreSQL и рациональные соображения крайне редко входят в противоречия друг с другом. Здесь ты не совсем права: у тебя свои рац. соображения, у создателей Postgres - свои. Если понять их рац. соображения, то начинаешь восхищаться, если цепляешься за собственные - иногда плеваться хочеться. PostgreSQL особенный продукт (как в прочем и остальные) и его надо принимать. Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 11:12 |
|
||
|
увеличение производительности разделением таблицы
|
|||
|---|---|---|---|
|
#18+
Зато есть другие индексы, и они то и будут расти при каждом апдейте счетчика Поясни, пожалуйста. У нас есть таблица с полями f1 и f2. По полю f1 есть индекс, по полю f2 его нет. Мы выполняем UPDATE полей f2 и в результате этого будет расти индекс по f1. Я тебя правильно понял? Здесь ты не совсем права: у тебя свои рац. соображения, у создателей Postgres - свои. Если понять их рац. соображения, то начинаешь восхищаться, если цепляешься за собственные - иногда плеваться хочеться. PostgreSQL особенный продукт (как в прочем и остальные) и его надо принимать. Я не очень хочу вступать в философскую дискуссию, но не могу не отметить твою неправильную трактовку моей половой принадлежности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 17:25 |
|
||
|
увеличение производительности разделением таблицы
|
|||
|---|---|---|---|
|
#18+
За неправильную трактовку сразу извиняюсь. Помню как-то давно принял девушку за парня ;-) и начал рассказывать о своих взглядах на девушек. ilejnПоясни, пожалуйста. У нас есть таблица с полями f1 и f2. По полю f1 есть индекс, по полю f2 его нет. Мы выполняем UPDATE полей f2 и в результате этого будет расти индекс по f1. Я тебя правильно понял? Абсолютно. Для индексов в PostgreSQL (насколко я понимаю в данный момент) не существует операции "delete", в том числе и как составной части update. Каждый update для индекса - это всего лишь вставка новой строки. А удаление старых строк происходит только во время VACUUM. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.03.2006, 12:00 |
|
||
|
|

start [/forum/topic.php?fid=53&fpage=324&tid=2006526]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
29ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
| others: | 259ms |
| total: | 372ms |

| 0 / 0 |
