Pull to refresh
35
0
Юрий Жигадло @itcoder

Разработчик

Send message
не используйте внешние ключи
Вы поосторожнее с такими советами, а то люди придут, начитаются, а потом данные у них разъедутся — не делайте так никогда.
А на какую дату намечен релиз 8 версии не подскажите?
Пишите еще пожалуйста. Вообще довольно интересно получаеться, последний запрос после добавления индексов выдает explain:

explain analyze select * from test where j < 50000000 and i < 50000000 and h > 950000000;

Bitmap Heap Scan on test  (cost=99.57..731.89 rows=580 width=16) (actual time=4.173..7.049 rows=17 loops=1)
   Recheck Cond: (i < 50000000)
   Filter: ((j < 50000000) AND (h > 950000000))
   Rows Removed by Filter: 5026
   Heap Blocks: exact=541
   ->  Bitmap Index Scan on i1  (cost=0.00..99.43 rows=5218 width=0) (actual time=3.926..3.926 rows=5043 loops=1)
         Index Cond: (i < 50000000)
 Planning time: 0.137 ms
 Execution time: 7.099 ms
(9 rows)

Делаем:
vacuum analyze test;
И explain получается как у автора. Получается что пока не запустится автовакуум, после большого количества DDL запросов, запрос может строиться не оптимальным способом ?
Спасибо за материал, очень интересно, для сложного анализа данных просто бесценное расширение, особенно порадовала отрисовка картинки сразу из запроса, по сути можно в рантайме выбирать данные с хитрыми условиями за нужный диапазон смотреть как будет изменяться диаграмма. Интересно конечно как без PL/R сейсмологи данными оперируют?
В теории, если у вас работает одновременно 5 запросов на сервере при включении например: set max_parallel_degree = 4; и при условии что у вас 4 ядра, ресурсы должны распределиться на 4 ядра и запросы должны выполняться быстрее.
Что касается сортировок агрегаций и index scan – то скорее всего разработчики будут над ними работать в будущем, но пока этого нет.
Спасибо, за приглашение! можно к вам прямо после highload — конф. заскочить ). Если не сложно организуйте еще хорошую запись митапа чтобы было видно то, что показывают на доске, а то обычно качество видео не радует, и информация очень полезная — особенно для тех у кого нет возможности присутствовать.
Ждал развязки, но статья как то кончилась неожиданно.
По поводу автоваккуума, посмотрите презентации Ильи Космодемьянского, он на последнем PgDay как раз про это рассказывал
http://pgday.ru/ru/papers/31 Так же много интересного есть в видео записях того же летного PgDay 2015. p.s надеюсь организаторы мне не сломают руку за ссылку.
не сочтите за рекламу, но альтернатива pgMyAdmin для Postgres есть в продуктах jetBreans, панельку Database если настроить,
в запросах работает и автодополнение функций, названий таблиц и полей, скорость написания запросов можно в разы повысить + сохраняется история и все под рукой.
Спасибо! Довольно современное здание. Не могли бы вы дать ссылочку на акселератора?
Спасибо за статью, интересное решение, PgQ и правда довольно проблематичная очередь. Вопрос такой: Какую нагрузку выдерживает данная архитектура? если например высчитывать баланс одновременно 10 000 пользователей, получается что запросы сначала попадают в PgBouncer, какое то время висят в нем, ожидая очереди на запись, затем пишутся в Postgrgres, потому уже начинают срабатывать триггеры для отправки в amqp. На все уходят, хоть и не большие, но задержки. И еще интересно будет ли работать ваше решение по Round-robin схеме ?
Статья актуальная, но примеров кода маловато, хотелось бы побольше примеров применения из жизни.
Мне вместо трейтов больше нравятся поведения, их и тестами покрывать легче и поведение объекта более предсказуемо.
Да бросьте. Да у php есть свои недостатки в тех же стандартах, именование функций, но все это постепенно исправляется и улучшается от версии к версии. Свои задачи он прекрасно решает, а это низкий порок вхождения в язык, дешевизна разработки для бизнеса, просто огромное комьюнити которым не каждый язык может похвалиться. Да бывает что встречается плохой код, но это не от языка зависит, а от того, кто на нем пишет.
Прошу прощенья за перевод, в исходном варианте статья была немного сложной, хотелось потратить на неё немного больше времени, но не получилось.
Да, php был и остается живее всех живых, если еще после выхода PHP 7 проекты с веток 5.4 — 5.6 удастся почти безболезненно и быстро перевести, то цены не будет. В случае с python конечно грустно получилось, люди так до конца все и не перешли на 3 версию из за медленного перехода пакетов и библиотек.
Мне интересно, где же вы таких клиентов нашли которые сами дамп заливают, да еще через phpPgAdmin?
Спасибо за статью хороший материал. Попробовал зарегистрироваться, но вот что заметил:
— Мне пришло письмо с подтверждением email, но можно сделать его в красивом шаблоне, чтобы у пользователя было больше желания его подтвердить.
— При регистрации немного отпугивает select с выбором плана, мне кажется пользователя можно ввести ими в заблуждение, подумает что платить сразу надо.
— После подтверждения email попадаешь в личный кабинет, но сразу немного теряешься с чего начать, не хватает шагов действий.
Это конечно все мелочи, но конверсию кажется можно повысить.
А в целом понравилось, молодцы!
Получается переносили только данные. констрейнты, индексы, уже вручную создавали?
Да и хочется конечно технических подробностей, напрмер: как вы на продакшен все запускали, если сервис достаточно нагруженный, его останавливать не нельзя, данных в секунду много пишется, которые не хочется потерять, соответственно надо их как то синхронизировать с уже существующей базой поднятой из миграции?
Не увидел в статье. Как вы решаете задачу с переносом индексов?
У jsonb есть хорошее преимущество перед xml это возможность делать индексы па самим json объектам, с xml данными это сделать сложно, придется преобразовывать к  типу символьной строки  и потом создавать индекс. Да и почему бы нет, Potgres сейчас достаточно быстро развивается, приятно когда есть все.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity