Everything_is_bad, во 1 не ты а вы?) Мы вроде не знакомы. Во вторых именно так, внезапно, даже не через 9 часов а зацепку я получил минут через 15 после публикации, видать вселенная хотела чтобы я написал этот пост. И то, зацепка была малюсенькая, я вовремя ее увидел, размотал, переспросил два раза у клода, пошел в одну доку, оттуда в другую, оттуда в третью, проверил гипотезу, подрихтовал напильником и только тогда все начало летать как надо. Ну попробуйте сами по ключевым словам поискать из оригинального поста. Единственное что вы найдете, что нужно посмотреть накапливается ли статистика, увеличить statictic target потыкать analyze или отказаться от составных типов.
Everything_is_bad, жесть. Сударь, я видите ли три дня с этим бился, с гуглом и нейронками и дошел уже до написания кастомный функций аналитики на C. Подскажите пожалуйста, вы правда считаете что нужно быть таким токсичным? Вы правда думаете, что ктото "бежит сюда"? Особенно с вопросами в которых разбирается человек 200 на планете и даже документация слабо помогает? В век нейронок? Вы явно чтото путаете
Админы издеваются: 0xD34F
- это НЕ простой вопрос (особенно учитывая как мало разработчиков работает с мультивалютностью)
- он НЕ специфичен для PostgreSQL (он тут только для примера)
dimonchik2013, да, частично вы правы, вынес блок в вопрос. Совсем забыл что хранение в разных валютах еще добавит огромное количество веселья агрегациям. Опять же: есть решение для этого вопроса?
в мультивалютных системах главное вовсе не аггрегация (хотя она добавит большое количество боли) а хранение и преобразование. Сколько я видел систем где разработчики путались изза неудачного формата хранения - не пересчитать.
Bavashi, такое решение почти всегда бестолковое, за очень редким случаем, когда у оптимизатора таки встают на место мозги из-за него.
ЗЫ благодарю, я в курсе, я тут довольно редко появляюсь, но регулярно встречаю этого товарища. Собственно столько комментов, а нового я для себя почерпнул ровно ноль.
xmoonlight, ну по идее и базу бы сменить, я сам много лет работал с mysql, наразвлекался с ее оптимизатором по самое не хочу, но после oracle,postgresql я mysql за базу уже не считаю.
xmoonlight, ну сам ради развлечения опенсорсное решение, да еще допиленное, я точно переписывать не буду. А что мешает фирме, которая этим пользуется... Вы знаете, иногда для осознания нужны годы и годы ,чтобы решиться.
А по теме: я к тому же не могу придумать нормальной схемы данных под индивидуальный доступ к объектам в системе основанной на uuid ключах в mysql.
xmoonlight, а толку, если все селекты переписывать. Был бы пг можно было бы преобразовать все char(32) в uuid, char(64) в enum, развернуть индексы + сделать их частичными на критичных запросах. А уж если радикально менять то вместо таблицы подсунуть вьюшку и обложить ее instead of триггерами. Да даже денормализовать через hstore или jsonb
xmoonlight, вот только b-tree это не плоский список, там это выглядит чуть иначе. И я спрашивал не для себя а чтобы линковать народу, вместо объяснений.
xmoonlight, индекс? это очевидно. Кстати есть ссылочка где почитать касательно быстродействия индексов? Сама структура b-tree при составном индексе на это не так чтобы намекает, не первый раз мне вопрос такого порядка задают. Где то была статья у меня раньше где все доступно объяснялось, очень удобнокидать ее было, никак нагуглить немогу
