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

при аксиоме что delete не будет

и update

:)

тут есть проблема с инвариантом "индекс всегда смотрит на живой tid" проект с ним уже 30 лет живет

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

поэтому я тебя к нему отправлял

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

я тоже об этом думал... но практически не придумал как это сделать

запрос придется чутка править

чтобы where на батч айди добавить

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

ну и тут жопа что каждый раз придется всю таблицу сканить чтобы найти эти штуки

ну и тут жопа что каждый раз придется всю таблицу сканить чтобы найти эти штуки

это вроде минут 20-40 (на моих данных)

там был патчик чтобы новый индекс искать по существующему индексу

короче, если тебе реально важно, тебе надо идти в постгреспро

а если нет, то никто ничего не будет делать

короче, если тебе реально важно, тебе надо идти в постгреспро

что это значит?)

ну или в enterprisedb

заказывать патчи

мои руки не настолько длинные к сожалению

ну хз, если есть 1ккк данных, обычно есть бабки на патчик

там ценник гуманный

главное понять что ты хочешь

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

проект только заводится заново если вкратце

ок ок

Надо как следует объяснить, в чем идея. Можно даже рассказать её в блицдокладе на pgconf.ru. Если (если) хорошая вещь, можно сделать.

Надо как следует объяснить, в чем идея. Можно даже рассказать её в блицдокладе на pgconf.ru. Если (если) хорошая вещь, можно сделать.

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

Ivan, проблема примерно как в треде Книжника [HACKERS] Batch update of indexes он в нем предлагает делать частичные индексы, которые достраиваются после заливки данных одна из проблем с частичными индексами - куча доработок для оптимизатора чтобы он их брал но можно было бы сделать аналог alter index set invalid, но наоборот: чтобы использовался для запросов, но не обновлялся на лету например alter index set freeze после заливки данных сказать ему анфриз, чтобы как в патче выше влить в него свежие батч

ну или ждать колу, кажется так называлось lsm от Насти

@netneladno 20:16 начались билдиться индексы с мемом 4гб

Ок, обсудим это с Книжником и другими. Кола пока приостановилась.

кола ждет плагабл стореджа?

или просто нафиг

Нет,плагбл ей не нужно. Настя сейчас занимается инкрементальным бэкапом.

у меня складывается ощущение, что аля "alter index set freeze" сделать не такая катастрофическая задача но самому менять что-то в коде постгреса -- боюсь костылей

задача нормальная вообще, нюансов с не забыть тюплю после анфриза море + такого никогда не было, типа влил данные но через часть индексов они недоступны

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

срача будет море

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

ну потому что дубликат таблицы говорит что ты вгружал в А, а читал из Б потом поменял а тут вгружал в А, читал из А, но не видел

причем от плана к плану это меняется

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

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

иначе вообще конфуз

когда индекс отправляем в "кеш" -- никакой заморозки вроде не просится а вот когда началось построение нового - разумеется табличку надо заморозить на всё кроме select

Это на fastupdate похоже

похоже

такой вариант тоже обсуждался в треде

типа инсерт буфер для бтрии

это что за штука такая? не видел

в gin индексе

или в мускуле)

но как по мне такое лучше всего решается лсм

там тебе и свой индекс на микробач, и блум фильтр, и компакшн в фоне

LSM-tree ?

еп

myrocks возьми и не парься

ну там же тоже несколько деревьев насколько я понимаю

итого просадка на K

там несколько уровней деревьев да

которые мержатся

и которые в фоне сливаются

все как ты хочешь

сперва чтение медленно как с партициями - надо сходить в кучку файлов

myrocks возьми и не парься

это же какая-то mysql'овщина

а потом быстрее

у меня мультиколоночные индексы

вот ты зря, mysql за последние 4 года вырос так, что ппц

у меня мультиколоночные индексы

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

а где написано что майрокс не может мультиколумн?

хм :)

а потом быстрее

а когда это -- потом?)

когда вольются слои

надо глянуть можно ли форсить мажор компакшон

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

там конечно свои нюансы бывают

но где их нет

Так, а если на примере: в пзу уровне у нас допустим 700кк записей в озу уровень я вставил пачку 30кк (и она туда поместилась) 1. данные из озу ещё не скочевали в пзу -- какая асимптотика поиска по такому "индексу"? 2. все данные перекочевали в пзу -- будет ли тут чистый логарифм?

с версии 3.8 уже думаю монгу всем советовать

напомню также, что у меня по меньшей мере 7 индексов, среди которых 2 -- мультиколумн

блин, пытаюсь нагуглить рид паф

ничего сходу хорочего не нашел

к тому же сервер может бабахнуть и всё из оперативки полетит как из редиса( и фиг что потом разберешь

надо прочитать N уровней, там сортированые данные - логарифм будет

но не "чистый"

тогда вопрос на сколько "грязный" :)

когда пишешь - и л0 компакшн не успел, читаешь еще больше

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

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

но на линк бенче (поинт лукапы) майрокс ебет иннодб

извини, но сегодня тебе уже придется самому искать презенташки и вики

ещё немаловажный момент: выборка иногда может возвращаться где-то по сотне строк

извини, но сегодня тебе уже придется самому искать презенташки и вики

параллельно делаю это :)

ещё немаловажный момент: выборка иногда может возвращаться где-то по сотне строк

фигня

ну и ренж сканы там ок - сортировка ж

хм