|
|
|
индексы с "include"
|
|||
|---|---|---|---|
|
#18+
Добрый день. Вопрос такого плана. Есть ли в PostgreSQL создать индекс где в теле индекса свои поля, а в листовом уровне плюс дополнительные. Я просто занимаюсь MS-SQL этим пользуюсь часто... а вот в этой тематике пока не але ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2015, 15:21 |
|
||
|
индексы с "include"
|
|||
|---|---|---|---|
|
#18+
Про PG не скажу, а вот что пользуешься ты этим часто -- не очень хорошо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2015, 18:06 |
|
||
|
индексы с "include"
|
|||
|---|---|---|---|
|
#18+
zasandator, а что вы хотите сделать и для чего? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2015, 18:18 |
|
||
|
индексы с "include"
|
|||
|---|---|---|---|
|
#18+
zasandator, ios. Index only scan -- это думаю почти совсем то ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2015, 09:09 |
|
||
|
индексы с "include"
|
|||
|---|---|---|---|
|
#18+
MasterZivПро PG не скажу, а вот что пользуешься ты этим часто -- не очень хорошо. Очень интересно ))). В чем же здесь "плохость"? )))) Если говорить, что много индексов плохо, я понимаю прекрасно )))). С инклюд еще больше место будет. Но без индексов или с определенными индексами - это дело конкретных случаев на мой взгляд. Вообще постгри странны.... В MS-SQL в таблице tbl(a int, b int, c int), создаю индекс create index ix1 on tbl (a,b) - (индекс BTree). И далее делаю запрос такой - select a,b from tbl. происходит сканирование по индексу ix1. В постгри тоже самое когда делаю, в плане показывает - Seq Scan — читается вся таблица. Не понимаю для чего? В постгри в индексе не хранятся сами данные? это же бтри... или в постгри бтри другое чем в МССКЛ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2015, 10:39 |
|
||
|
индексы с "include"
|
|||
|---|---|---|---|
|
#18+
zasandator, выложите сюда план запроса. Во-первых, таблица может быть маленькая, выборка может быть неизбирательная, планировщик может решить, что секскан выгоднее индекс-скан. Кстати, так бывает. Кроме того, индекс-онли-скан работает только для относительно мало меняемых таблиц, если установлена видимость для блока и если все указанные в запросе поля содержатся в индексе. И в дополнение - index only scan для postgresql 9.2 и выше. Как-то так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2015, 11:28 |
|
||
|
индексы с "include"
|
|||
|---|---|---|---|
|
#18+
zasandator, PostgreSQL хранит данные о видимости записей в самих записях. Поэтому после прохода по индексу надо обязательно лезть в таблицу. При таком раскладе SeqScan только по таблице всяко быстрее. Исключение — IndexOnlyScan, требует вакуумированной таблицы без новых изменений. С моей точки зрения странный как раз MS-SQL. И это не “постгри”, а постгрес. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2015, 11:29 |
|
||
|
индексы с "include"
|
|||
|---|---|---|---|
|
#18+
zasandatorMasterZivПро PG не скажу, а вот что пользуешься ты этим часто -- не очень хорошо. Очень интересно ))). В чем же здесь "плохость"? )))) Если говорить, что много индексов плохо, я понимаю прекрасно )))). С инклюд еще больше место будет. Но без индексов или с определенными индексами - это дело конкретных случаев на мой взгляд. Вообще постгри странны.... В MS-SQL в таблице tbl(a int, b int, c int), создаю индекс create index ix1 on tbl (a,b) - (индекс BTree). И далее делаю запрос такой - select a,b from tbl. происходит сканирование по индексу ix1. В постгри тоже самое когда делаю, в плане показывает - Seq Scan — читается вся таблица. Не понимаю для чего? В постгри в индексе не хранятся сами данные? это же бтри... или в постгри бтри другое чем в МССКЛ? Тонкость в том что seq scan по таблице - это линейное чтение с диска. А index only scan по индексу - случайное чтение с диска и с хорошей вероятностью будет медленнее. Можно: 1)заэнфорсить IOS через set enable_seq_scan to 0; или 2)сделать select a,b from tbl order by a,b; тогда вероятнее всего IOS будет. PS: если у вас в таблице 1-2-10 строк то seq scan вообще всегда дешевле. Планы зависят от размеров таблицы и индекса поэтому тестирование на пустых данных - бесмысленно. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2015, 11:29 |
|
||
|
индексы с "include"
|
|||
|---|---|---|---|
|
#18+
zasandator, zasandatorSeq Scan — читается вся таблица. На данный момент времени в оптимизаторе постгреса нет возможности делать Index only scan. Такое ожидаем только в версии 9.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2015, 11:35 |
|
||
|
индексы с "include"
|
|||
|---|---|---|---|
|
#18+
Maxim BogukА index only scan по индексу - случайное чтение с дискаЕсли postres не может сделать такое же последовательное чтение only индекса, как и таблицы, ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2015, 11:39 |
|
||
|
индексы с "include"
|
|||
|---|---|---|---|
|
#18+
p2.Maxim BogukА index only scan по индексу - случайное чтение с дискаЕсли postres не может сделать такое же последовательное чтение only индекса, как и таблицы,то это недостаток реализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2015, 11:39 |
|
||
|
индексы с "include"
|
|||
|---|---|---|---|
|
#18+
grufoszasandator, zasandatorSeq Scan — читается вся таблица. На данный момент времени в оптимизаторе постгреса нет возможности делать Index only scan. Такое ожидаем только в версии 9.5 Чтооооооо???? Вы вообще о чем? IOS уже несколько лет как есть. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2015, 11:43 |
|
||
|
индексы с "include"
|
|||
|---|---|---|---|
|
#18+
grufoszasandator, zasandatorSeq Scan — читается вся таблица. На данный момент времени в оптимизаторе постгреса нет возможности делать Index only scan. Такое ожидаем только в версии 9.5 Хм. А мужики не знают! Код: sql 1. 2. 3. 4. Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2015, 11:44 |
|
||
|
индексы с "include"
|
|||
|---|---|---|---|
|
#18+
ОКТОГЕН, да, верно. такое название операции есть. К сожалению это не совсем то, что хотел zasandator Дело в том, что в MSSQL есть два понятия к индексу 1. индексный доступ - Index Seek 2. последовательный доступ - Index Scan у нас же есть только одно понятие 1. индексный доступ - Index Scan и тут вот как раз и начинаются непонятки для новичков. В наименовании ведь слова Scan... Смысл оптимизации MSSQL при использовании сканирования индекса, в том, что в взять в обработку объект меньшего размера - 2 поля, в то время как сама таблица состоит из 3-х полей. Текущая реализация Index Only Scan using table1_idx1 on table1... похожа на это, но срабатывает только если мы выбираем еще и мало записей, то есть эффективное использование индекса. А это все же не то, что хотел zasandator Да, это ограничение в текущей реализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2015, 11:59 |
|
||
|
индексы с "include"
|
|||
|---|---|---|---|
|
#18+
p2.Если postres не может сделать такое же последовательное чтение only индекса, как и таблицы, то это недостаток реализации. Во-первых, Вы так говорите, как будто кто-то это может сделать в общем случае . ;) Например, упомянутый тут MSSQL --- в общем случае не может. Во-вторых, выгоды в этом на практике обычно нет, т.к. надо сильно постараться заполнить индекс так, чтобы от этого был выигрыш. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2015, 12:00 |
|
||
|
индексы с "include"
|
|||
|---|---|---|---|
|
#18+
grufos, Ну собственно да... индекс скан меня и интересует в том числе. Ну индекс же не только для поиска (в МССКЛ) а для сортировки в том числе. Если вот запрос сделать - select a,b from tbl order by a asc, b asc то будет именно индекс скан и все - без сортировки. если сделать order by b, a - сканирование индекса (потому что других нет и этот индекс даст наименьшее количество чтений с диска) и плюс в план добавится довольно таки тяжелая сортировка. А че в постгрес? если есть индекс ix1(a,b) будет чтение с heap + sort? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2015, 12:12 |
|
||
|
индексы с "include"
|
|||
|---|---|---|---|
|
#18+
Ну а вообще... такая ситуация... 2 таблицы одна с небольшим количеством данных, другая разв 100 больше данных, соединение запрос к примеру такой select small.f1, large.f2 from small join large on small.id = large.id в плане вижу скан small далее скан large и хэшсоединение. Пытаюсь его (как в МС-СКЛ) оптимизировать на MS-SQL создал бы типа такого - create index ix1_large on large (id) include (f2). Ну фиг с ним, не нашел в постгрес инклуд, попытался увеличить покрытие индекса так - index (id, f2), в надежде что план будет примерно такой: скан мелкой таблицы, поиск (сиик = онлииндексскан) в большой таблице и нестед луп лукап. И нифига! хеш соединение с полным сканом большой таблицы! Что я не понимаю? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2015, 12:20 |
|
||
|
индексы с "include"
|
|||
|---|---|---|---|
|
#18+
zasandator <>в надежде что план будет примерно такой: скан мелкой таблицы, поиск (сиик = онлииндексскан) в большой таблице и нестед луп лукап. <>обычно это удаётся навязать через LATERAL [ с LIMIT-ом в нём, заведомо покрывающем разумное количество (ограничением кардинальности, если позволите). ибо если количество заведомо неразумно => хешджойн будет быстрее туевой хучи нестед лупов] ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2015, 12:26 |
|
||
|
индексы с "include"
|
|||
|---|---|---|---|
|
#18+
qwwq, Я понимаю это - представляю примерно как работает оптимизатор запросов )))))). Ну small - 100 строк, large - 10 млн. какой смысл эти 2 таблицы делать хэшджоин с полным сканированием? В моем понимании (обычно MS-SQL так и делает) сканирует мелкую таблицу и 100 нестед луп... Понятно, что если строк не 100 а 1000 или больше кардинальность меняется и план может поменяться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2015, 12:42 |
|
||
|
индексы с "include"
|
|||
|---|---|---|---|
|
#18+
zasandatorНу а вообще... такая ситуация... 2 таблицы одна с небольшим количеством данных, другая разв 100 больше данных, соединение запрос к примеру такой select small.f1, large.f2 from small join large on small.id = large.id в плане вижу скан small далее скан large и хэшсоединение. Пытаюсь его (как в МС-СКЛ) оптимизировать на MS-SQL создал бы типа такого - create index ix1_large on large (id) include (f2). Ну фиг с ним, не нашел в постгрес инклуд, попытался увеличить покрытие индекса так - index (id, f2), в надежде что план будет примерно такой: скан мелкой таблицы, поиск (сиик = онлииндексскан) в большой таблице и нестед луп лукап. И нифига! хеш соединение с полным сканом большой таблицы! Что я не понимаю? Для детального ответа - приведите полный тестовый пример. Генерация данных + explain analyze проблемного запроса. Тогда можно будет что то ответить. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2015, 12:45 |
|
||
|
индексы с "include"
|
|||
|---|---|---|---|
|
#18+
qwwq, ну вот на конкретном примере... может есть какие подсказки хинты? Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. Как на этом примере заставить поиск по индексу? ну или хотя бы сканирование индекса (что бы f3 не захватывал) сделать? может хинтами? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2015, 12:46 |
|
||
|
индексы с "include"
|
|||
|---|---|---|---|
|
#18+
PgSQLAnonymousp2.Если postres не может сделать такое же последовательное чтение only индекса, как и таблицы, то это недостаток реализации. Во-первых, Вы так говорите, как будто кто-то это может сделать в общем случае . ;) Например, упомянутый тут MSSQL --- в общем случае не может. Во-вторых, выгоды в этом на практике обычно нет, т.к. надо сильно постараться заполнить индекс так, чтобы от этого был выигрыш. ;)Не скажу за mssql, но оракл умеет делать последовательное сканирование индекса достаточно давно. Вопрос всего лишь в организации листовых блоков. Что значит "заполнить индекс", я не понял. Но выгода такая же как и с таблицей - последовательное чтение блоков на неssd дает значительное преимущество. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2015, 13:03 |
|
||
|
индексы с "include"
|
|||
|---|---|---|---|
|
#18+
zasandatorqwwq, ну вот на конкретном примере... может есть какие подсказки хинты? Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. Как на этом примере заставить поиск по индексу? ну или хотя бы сканирование индекса (что бы f3 не захватывал) сделать? может хинтами? всетаки сделайте нормальный test case который можно руками прогнать. А там посмотрим. Какая часть таблицы large в вашем примере будет выбираться? -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2015, 13:17 |
|
||
|
индексы с "include"
|
|||
|---|---|---|---|
|
#18+
zasandator<> Как на этом примере заставить поиск по индексу? ну или хотя бы сканирование индекса (что бы f3 не захватывал) сделать? может хинтами? у меня и просто так не хешит: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. ЧЯДНТ ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2015, 13:20 |
|
||
|
индексы с "include"
|
|||
|---|---|---|---|
|
#18+
p2.Не скажу за mssql, но оракл умеет делать последовательное сканирование индекса достаточно давно. Вопрос всего лишь в организации листовых блоков. Что-то я сходу не нашёл, можно ссылку? Кстати, я правильно понял, что Вы имели в виду простое последовательное чтение страниц индекса (игнорируя всякие ссылки между узлами B+-дерева)? p2.Что значит "заполнить индекс", я не понял. Можно вставлять в индекс по-разному, в том числе так, что в итоге листья распределяются на диске совсем не по порядку ключа. p2.Но выгода такая же как и с таблицей - последовательное чтение блоков на неssd дает значительное преимущество. Да это ясно, а вот как Oracle этого добивается при активно модифицируемом индексе? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2015, 13:52 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=38966692&tid=1997971]: |
0ms |
get settings: |
7ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
218ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
90ms |
get tp. blocked users: |
2ms |
| others: | 210ms |
| total: | 567ms |

| 0 / 0 |
