Size: a a a

pgsql – PostgreSQL

2020 August 21

K

Kosta in pgsql – PostgreSQL
таблицы используются только на чтение, insert/update/delete не предполагается.

Покрывающий индекс дал огрмный прирост

https://gist.github.com/k0nsta/3f933f4ca45bf38acb4dc11ab849cb87
источник

s

sexst in pgsql – PostgreSQL
Yaroslav Schekin
Там условие по дате только в одной таблице (не факт, что в другой вообще даты есть).
Т.е. "правильное" партиционирование тут сделать непросто.
И даже в случае партиционирования по датам, выигрыш будет либо тогда, когда при заполнении таблицы происходит много updates/deletes (повторных inserts), либо тогда, когда условия запроса как раз делают выгодным этот индекс по датам не использовать вообще.
Ну я и написал, что такой corner case, что я бы не рассчитывал на него)
источник

K

Kosta in pgsql – PostgreSQL
sexst
BTW, r5.large на 0.03$ дороже (0,126 vs 0,096 USD за час), но оперативки уже не 8гб, а хотя бы 16гб.
это самая простая проблема для меня, решу ее на сл неделе ) Но прежде хотелось бы разобраться и понять на уровне бд. Спасибо сообществу!
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Kosta
таблицы используются только на чтение, insert/update/delete не предполагается.

Покрывающий индекс дал огрмный прирост

https://gist.github.com/k0nsta/3f933f4ca45bf38acb4dc11ab849cb87
Да, неплохо, но Вы рано радуетесь. ;)
Вот это
 Nested Loop  (cost=1.14..9767503.73 rows=25565999 width=42) (actual time=51.273..31677.748 rows=22276046 loops=1)
  Buffers: shared hit=516081 read=12503, local hit=38255 read=23765

говорит о том, что читает этот запрос, потенциально, до 4 Гб.
Просто в данном случае почти всё было взято из RAM. На production так не будет, и запрос (при вышеупомянутом cache hit) будет выполняться секунд 20, наверное (не факт, конечно, я внимательно не смотрел)...
источник

s

sexst in pgsql – PostgreSQL
Yaroslav Schekin
Да, неплохо, но Вы рано радуетесь. ;)
Вот это
 Nested Loop  (cost=1.14..9767503.73 rows=25565999 width=42) (actual time=51.273..31677.748 rows=22276046 loops=1)
  Buffers: shared hit=516081 read=12503, local hit=38255 read=23765

говорит о том, что читает этот запрос, потенциально, до 4 Гб.
Просто в данном случае почти всё было взято из RAM. На production так не будет, и запрос (при вышеупомянутом cache hit) будет выполняться секунд 20, наверное (не факт, конечно, я внимательно не смотрел)...
Один фиг сложно сделать что-то ещё при 8г оперативки и таких размерах данных. Откровенный недостаток памяти под нужные данные не обманешь.
источник

s

sexst in pgsql – PostgreSQL
Зато при докидывании памяти оно, насколько я полистал назад по сообщениям, раньше бы так и тормозило дальше, теперь же станет сильно лучше.
источник

K

Kosta in pgsql – PostgreSQL
Но это уже прогресс. Там место подходит, для дальнейших экспериментов не хватит.
План такой:
изменить тип инстанса, подкинуть ОЗУ, размер диска.
создать таблицу с временным отрезком 2008-2020, добавить индексы
анализ запроса.
источник

K

Kosta in pgsql – PostgreSQL
поговорил с аналитиками, им сейчас инетерсны данные за период 2008-2020, никаких четких планов по использованию других нет, так что я думаю под текущие задачи создать усеченную таблицу, потом ее прибить.
источник

D

Den in pgsql – PostgreSQL
Привет всем. Можно ли при CREATE TABLE указать определенное значение столбца для всех записей? Т.е. у всех записей id будет = 1.
источник

AS

Anatoly Shirokov in pgsql – PostgreSQL
Den
Привет всем. Можно ли при CREATE TABLE указать определенное значение столбца для всех записей? Т.е. у всех записей id будет = 1.
DEFAULT:
CREATE TABLE foo (
  id integer DEFAULT 1
)
источник

D

Den in pgsql – PostgreSQL
ну не совсем то, DEFAULT будет в случае если не указано другое
источник

A

Alexander in pgsql – PostgreSQL
Den
ну не совсем то, DEFAULT будет в случае если не указано другое
Сделай view-ху.
источник

KK

Konstantin K in pgsql – PostgreSQL
Den
ну не совсем то, DEFAULT будет в случае если не указано другое
не указывай другое :)
источник

D

Den in pgsql – PostgreSQL
ладно, тогда объясню подробнее что хочу сделать. Хочу создать single-row таблицу для хранения некоторых конфигов. Как гарантировать что в данную таблицу не будет добавлено более одной записи? Только триггеры - решение?
источник

D

Den in pgsql – PostgreSQL
почему хотел сделать одно значение на все записи - чтобы потом повесить на этот ряд UNIQUE и таким образом запретить создание новых записей
источник

A

Alexander in pgsql – PostgreSQL
Den
почему хотел сделать одно значение на все записи - чтобы потом повесить на этот ряд UNIQUE и таким образом запретить создание новых записей
Уж лучше триггер.
источник

D

Den in pgsql – PostgreSQL
понял, спасибо
источник

A

Alexander in pgsql – PostgreSQL
@f1kus можно, конечно, еще забабахать check constraint на то, чтобы id = 1, а затем сделать unique на id, но триггер тут всё равно лучше.
источник

D

Den in pgsql – PostgreSQL
кстати да, check constraint тоже вариант
источник

A

Alexander in pgsql – PostgreSQL
Den
кстати да, check constraint тоже вариант
Сделай триггер, пожалуйста. Иначе я не прощу себя за то, что подсказал тебе про check constraint.
источник