YS
никогда не говори никогда (ц)
А в чём он неправ? По-моему, всё именно так.
Size: a a a
2021 February 20
DG
если оптимизатору нечего выбирать, он ничего и не выберет полезного
DG
лучше насоздавать, поэксплуатировать, посмотреть по статистике, что понравилось и использовалось чаще всего с явным выиграшем в производительности
A🇷
Yaroslav Schekin
> Я имел в виду, может можно как-то сократить sql запрос
По созданию таблицы? Или какой?
> Например в mysql можно создавать индексы на столбцы во время создания самой таблицы
Правда? А каким образом, можете показать пример?
> Но я так понимаю в постгресе так нельзя
Нет, именно индексы — нельзя.
Можно создавать только constraints (т.к. некоторые реализованы как индексы, то нужные индексы в таких случаях автоматически создаются).
По созданию таблицы? Или какой?
> Например в mysql можно создавать индексы на столбцы во время создания самой таблицы
Правда? А каким образом, можете показать пример?
> Но я так понимаю в постгресе так нельзя
Нет, именно индексы — нельзя.
Можно создавать только constraints (т.к. некоторые реализованы как индексы, то нужные индексы в таких случаях автоматически создаются).
Если это не сарказм, то вот
CREATE TABLE t (
c1 char(10),
c2 char(20),
INDEX (c1)
);
CREATE TABLE t (
c1 char(10),
c2 char(20),
INDEX (c1)
);
YS
Если это не сарказм, то вот
CREATE TABLE t (
c1 char(10),
c2 char(20),
INDEX (c1)
);
CREATE TABLE t (
c1 char(10),
c2 char(20),
INDEX (c1)
);
Нет, не сарказм, и в PostgreSQL такого нет.
YS
лучше насоздавать, поэксплуатировать, посмотреть по статистике, что понравилось и использовалось чаще всего с явным выиграшем в производительности
Т.е. если у Вас 4 "подходящих" поля, Вы сначала создаёте 64 индекса (а если пять — то 325 и т.д.), а потом "смотрите по статистике", серьёзно?
DG
Yaroslav Schekin
Т.е. если у Вас 4 "подходящих" поля, Вы сначала создаёте 64 индекса (а если пять — то 325 и т.д.), а потом "смотрите по статистике", серьёзно?
более чем, но с одной оговоркой
если кошелёк, конечно, позволяет
если кошелёк, конечно, позволяет
AL
лучше насоздавать, поэксплуатировать, посмотреть по статистике, что понравилось и использовалось чаще всего с явным выиграшем в производительности
ммм, звучит как попытка троллинга, вы действительно так считаете?
DG
Yaroslav Schekin
Т.е. если у Вас 4 "подходящих" поля, Вы сначала создаёте 64 индекса (а если пять — то 325 и т.д.), а потом "смотрите по статистике", серьёзно?
что такое "подходящие поля" ?
в случае, если запросов к таблицам вообще никто ещё не видел ?
в случае, если запросов к таблицам вообще никто ещё не видел ?
YS
более чем, но с одной оговоркой
если кошелёк, конечно, позволяет
если кошелёк, конечно, позволяет
Хмм... т.е. Вы в production осознанно замедляете все insert/update в 64, или 325, и так далее раз (примерно)?
А потом делаете что, конкретно (т.е. как выполняете "посмотреть по статистике")?
И как при такой перегруженности индексами определяется "явный выигрыш в производительности"?
> что такое "подходящие поля" ?
Те, которые вообще могут участвовать в WHERE или ORDER BY. К примеру, поля с типом JSON к таким точно, а bytea почти наверняка не относятся.
А потом делаете что, конкретно (т.е. как выполняете "посмотреть по статистике")?
И как при такой перегруженности индексами определяется "явный выигрыш в производительности"?
> что такое "подходящие поля" ?
Те, которые вообще могут участвовать в WHERE или ORDER BY. К примеру, поля с типом JSON к таким точно, а bytea почти наверняка не относятся.
DG
Yaroslav Schekin
Хмм... т.е. Вы в production осознанно замедляете все insert/update в 64, или 325, и так далее раз (примерно)?
А потом делаете что, конкретно (т.е. как выполняете "посмотреть по статистике")?
И как при такой перегруженности индексами определяется "явный выигрыш в производительности"?
> что такое "подходящие поля" ?
Те, которые вообще могут участвовать в WHERE или ORDER BY. К примеру, поля с типом JSON к таким точно, а bytea почти наверняка не относятся.
А потом делаете что, конкретно (т.е. как выполняете "посмотреть по статистике")?
И как при такой перегруженности индексами определяется "явный выигрыш в производительности"?
> что такое "подходящие поля" ?
Те, которые вообще могут участвовать в WHERE или ORDER BY. К примеру, поля с типом JSON к таким точно, а bytea почти наверняка не относятся.
я не предлагал создавать одновременно все сразу, я предлагал не пропустить все возможности
YS
я не предлагал создавать одновременно все сразу, я предлагал не пропустить все возможности
Хмм... тогда я не понял, о чём речь.
Можете объяснить или показать пример?
Можете объяснить или показать пример?
DG
Yaroslav Schekin
Хмм... тогда я не понял, о чём речь.
Можете объяснить или показать пример?
Можете объяснить или показать пример?
ну как минимум,
on tbl(c1,c2)
on tbl(c2,c1)
уже сильно разные по полезности индексы, В ЗАВИСИМОСТИ от запросов
on tbl(c1,c2)
on tbl(c2,c1)
уже сильно разные по полезности индексы, В ЗАВИСИМОСТИ от запросов
YS
ну как минимум,
on tbl(c1,c2)
on tbl(c2,c1)
уже сильно разные по полезности индексы, В ЗАВИСИМОСТИ от запросов
on tbl(c1,c2)
on tbl(c2,c1)
уже сильно разные по полезности индексы, В ЗАВИСИМОСТИ от запросов
И дальше, дальше-то что? ;) Т.е. вот есть у Вас 4 "подходящих" поля, как Вы поступаете?
AL
Ребят привет. Вопрос - куда в PGAdmin 4 выводятся уведомления из RAISE NOTICE?
DG
Yaroslav Schekin
И дальше, дальше-то что? ;) Т.е. вот есть у Вас 4 "подходящих" поля, как Вы поступаете?
pg_stat_user_indexes
YS
pg_stat_user_indexes
Что "pg_stat_user_indexes"? ;)
Вы можете понятно объяснить, на примере?
Т.е. какие индексы создаёте, и https://t.me/pgsql/285192 ?
Вы можете понятно объяснить, на примере?
Т.е. какие индексы создаёте, и https://t.me/pgsql/285192 ?
PD
Всем привет, подскажите пожалуйста, как сделать такой запрос, в SQL пока новичок. Надо обновить поле exitPrice и suspenderPrice в зависимости от значения поля difference
AZ
Если логика не сложная, пару случаев, то можно попробовать "case".
Или сделай несколько update под конкретные варианты, если операция разовая
Или сделай несколько update под конкретные варианты, если операция разовая
PD
Alexey Zhuravlev
Если логика не сложная, пару случаев, то можно попробовать "case".
Или сделай несколько update под конкретные варианты, если операция разовая
Или сделай несколько update под конкретные варианты, если операция разовая
Может быть такое что нужно будет обновить 1000 таких записей