Индекс имеет смысл в нескольких случаях - даже если вы выбирает все записи из таблицы - но не все поля - планировщик может взять индекс построенный по всем фильтруемым и выбираемым полям - так называемый index only scan. А вот если хотя бы одно выбираемое поле не попадает в индекс - начинает играть роль селективность. И субъективно - если выбирается хотя бы 30-40% записей - выгоднее seq scan

На четырех страницах ничего планировать не надо, их надо просто прочитать, если кост строки не запредельный

я не знаю деталей планера, но ты уверен что там есть катоф вида «не ищем дальше если и кост этого ниже XXX»?

катоф "не инлайним, если кост больше ХХХ" я точно видел

я просто хочу получить скорость выше мыскуля... :)

а, ну сек скан против индекса считает кол-во записей, кол-во страничек и их расположение и умножает на косты и все

я просто хочу получить скорость выше мыскуля... :)

это сложно

я просто хочу получить скорость выше мыскуля... :)

замедли мускуль))

что то вы пессимисты какие то :)

Лiл

что то вы пессимисты какие то :)

абсолютная скорость на одном запросе в выборе базы стоит месте на шестом

скорее дело в весах на параметрах

к слову мускуль 8.0 вообще огонь я вижу всё меньше и меньше причин юзать постгрес

@Casus_Improvisus покажи explain (analyze, verbose, buffers) запроса с seq scan и без него

особенно интересно посмотреть в buffers

@Casus_Improvisus покажи explain (analyze, verbose, buffers) запроса с seq scan и без него

я показал с секскан

сейчас без покажу

buffers не вижу

без секскан: https://pastebin.com/NcgHg9Ha

buffers — это где?

explain (analyze, verbose, buffers)

первая строчка синтаксиса в https://www.postgresql.org/docs/10/static/sql-explain.html

а если время планирования вычесть, то получается 3.6мс небось даже быстрее мускуле будет лол

ну простейшая программа даёт что на массиве больше 3 элементов быстрее дерево/хеш, чем последовательный скан

Парни из redis все hashmap хранят как список, пока не дорастет до 256 (кажется) элементов и это работа с памятью. С диском наверно все 2048 прочитать проще подряд, тем более придефолтных read ahead

https://pastebin.com/VyKbLRMn https://pastebin.com/YjrEkj0j

Index scan: Buffers: shared hit=231 Seq scan: Buffers: shared hit=212

ты читаешь лишних (231-212)*8=152 килобайта при индексскане

копейки

я не понимаю, почему это должно быть быстрее

оно может занимать, например, столько же, если у тебя страничка процессора больше, чем эта разница

потому что читаешь ты всё равно из памяти

я не понимаю, почему это должно быть быстрее

всё в памяти. речь не только об объёме данных но и о работе с ними

о какой работе, memcmp поделать?

всё в памяти. речь не только об объёме данных но и о работе с ними

я не понимаю о чем мы тут сремся, но есть такое понятие как point chaising

попробовал заменить все text на CHAR(XX) как они в оригинальной мыскл дб. стало ещё медленнее

ггг

лучший вариант - написать это на ассемблере

если не получается, на си

тестовая программа на перле, что вобщем с учётом реализации и так на си

потом результат переписать в план постгреса

а потом план постгреса переписать в sql

всегда так делаю, когда надо, чтобы быстро работало

но если тебя не устраивает время работы sql-запроса в 4мс, ты что-то катастрофически косячишь в архитектуре

ладно, суть вопроса: https://dev.mysql.com/doc/index-other.html world database — загружаю в мыскл. то же самое в пг (10). сравниваю скорость выполнения запроса (есть в пастебине)

мыскл даёт 500+ запросов в секунду, пг даёт 400+ в секунду

а зачем тебе 500 запросов джоина страны к городу к языку в секунду?

но если тебя не устраивает время работы sql-запроса в 4мс, ты что-то катастрофически косячишь в архитектуре

в данном случае всё абстрактно. но на практике я бы хотел чтобы всё исполнялось на за Х мс, а вообще мгновенно

у тебя в школе метрология была? :)

ладно, суть вопроса: https://dev.mysql.com/doc/index-other.html world database — загружаю в мыскл. то же самое в пг (10). сравниваю скорость выполнения запроса (есть в пастебине)

Какие индексы в мыскуле?

метрология? впервые такое слово слышу

постгрес зато не падает как мускуль, как парень который только учится ходить))

в данном случае всё абстрактно. но на практике я бы хотел чтобы всё исполнялось на за Х мс, а вообще мгновенно

сделай матвью и обновляй когда города заливаешь

Какие индексы в мыскуле?

там внутри всё есть. но в пг я те же самые создал

постгрес зато не падает как мускуль, как парень который только учится ходить))

у пг масса плюсов. но вот тут я ожидал что он не уступит

мне кажется, всех людей, говорящих "хочу, чтобы вообще мгновенно", надо отправлять на бесконечно закольцованный курс универской метрологии, пока у них не отобьётся желание абстрактного перфекционизма

собственно, я пришёл с вопоросом можно ли ускорить пг, чтобы было не хуже мыскуля. а получаю "тебе это не нужно". странные вы.

у пг масса плюсов. но вот тут я ожидал что он не уступит

Если мне память не изменяет - mysql может использовать несколько индексов по 1 таблице в 1 запросе. Давайте план из мыскуля.

да, денормализуй таблицу

по денормализованной с индексом по language должно быть шустрее

да, денормализуй таблицу

Зачем - пусть покрывающий индекс бахнет. Или частичный под этот конкретный запрос

собственно, я пришёл с вопоросом можно ли ускорить пг, чтобы было не хуже мыскуля. а получаю "тебе это не нужно". странные вы.

ну сделай матвью же, статичные данные

Зачем - пусть покрывающий индекс бахнет. Или частичный под этот конкретный запрос

нельзя сделать покрывающий индекс по нескольким таблицам

Я по той по которой фильтрация имел ввиду

Она будет читаться index only

index only отдельная боль

собственно, я пришёл с вопоросом можно ли ускорить пг, чтобы было не хуже мыскуля. а получаю "тебе это не нужно". странные вы.

А дамп бд можно?

на статичных и append-only таблицах часто внезапно оказывается, что вакуум никогда не пришёл и visibility map не заморожена

я про это ещё на pgconf расскажу

на статичных и append-only таблицах часто внезапно оказывается, что вакуум никогда не пришёл и visibility map не заморожена

Видимо мне везло. Или все дело в периодическом vacuum analyze всего

Я бы все же поглядел на план из мыскуля

И послушал бы @alexey_kopytov , по поводу того как используются индексы в mysql

мыскл даёт 500+ запросов в секунду, пг даёт 400+ в секунду

ты после заливки базы делал vacuum analyze? На основе статистики пг оптимизирует план запроса

omg, это же Казус! #unix.ru форева!

ты после заливки базы делал vacuum analyze? На основе статистики пг оптимизирует план запроса

Он же делал explain analyze

Это не то же самое вроде

это совсем не то же самое

в explain аналайз значит, что надо выполнить запрос и посчитать, сколько чего выполнялось, а в вакууме - взять табличку и построить по ней гистограммы

в explain аналайз значит, что надо выполнить запрос и посчитать, сколько чего выполнялось, а в вакууме - взять табличку и построить по ней гистограммы

+1

А дамп бд можно?

я же дал линк. ещё раз: http://downloads.mysql.com/docs/world.sql.zip

ты после заливки базы делал vacuum analyze? На основе статистики пг оптимизирует план запроса

я делал аналайз на каждую новую таблицу

omg, это же Казус! #unix.ru форева!

воистину! :)

Недавно сам тестил скорость после апгрейда с 9.6 на 10 - пока не выполнил vacuum (abalyze) full, статистика не заполнилась и 10 выполняла запросы медленнее, не смотря на gather

я же дал линк. ещё раз: http://downloads.mysql.com/docs/world.sql.zip

Дамп вашей pg базы. Нет желания приводить типы

ну, кстати, есть ещё одна разница — в мыскуль базе кодировка латин1, а у пг ютф8, мне пришлось конвертировать исходник

на статичных и append-only таблицах часто внезапно оказывается, что вакуум никогда не пришёл и visibility map не заморожена

и шо делать? руками дергать?

Дамп вашей pg базы. Нет желания приводить типы

сорец меняется, сейчас вот снова буду с типами экспериментировать

и шо делать? руками дергать?

while true; do psql -c "vacuum;"; sleep 30; done также известный, как веловакуум

а если таблица append-only то вакуум в принципе почти бесплатный?

если на ней нет индексов

(а на ней есть, потому что тебе нужен index only scan)

а скан по индексу всегда полный

патч про это есть в -hackers

да, замена чар на варчар ускоряет запрос

@Casus_Improvisus text collate c

ладно, товарищи учёные, я так и не понял что делать с подземным стуком

prepared statement-ами ходи! они в пг вполовину ускоряют запрос, а в мускуле процентов на 20

ладно, товарищи учёные, я так и не понял что делать с подземным стуком

Вот дамп бы для эксперементов )

И план из мускуля

куда залить?

Да хоть в чат киньте - я думаю он сжатый - копейки