Например, таблица 10 млн записей, флаг isProcessed = fasle имеет 100 записей из этих 10 млн. Индекс будет полезен и будет работать для условия isProcessed = false При этом конечно стоит по условию делать опциональный индекс (или фукнциональный). Я правда не знаю, как PG умеет ли такое.

partial называется, умеет

Тогда это отлично подойдёт для такого индекса.

Сам индеск будет маленьким, а пользы от него будет много

на boolean столбцы имеет смысл индекс делать?

Нет. Имеет смысл делать условный индекс на более другие столбцы с условием по булевсскому. По полю field1 where bool_filed = true

Нет - это конечно, грубовато, но тем, не менее...

Нет. Имеет смысл делать условный индекс на более другие столбцы с условием по булевсскому. По полю field1 where bool_filed = true

Я таким макаром убивал пару индексов, создавал один и получал из 500+ мс на горячую, пару минут на холодную, 50 мс на холодную и 15+- мс на горячую.

А в логи можно писать количество возвращаемых строк.

А в логи можно писать количество возвращаемых строк.

explain можно записывать. но кажется нужен экстеншен для этого

Подскажите, пожалуйста, что-то сам туплю

Как получить значения из столбца alias, которым соответствуют userid, которые, в свою очередь взяты из другой таблицы

кажется непонятно объяснил ?

В общем, есть таблицы Participants, и UserAliases. Нужно из таблицы Participants взять UserId, и найти соответствующие этим id alias в таблицt Useraliases

как бы сквозной запрос

select Userid from Participants where ChatId=17

получаем список userid. А как из него получить alias, из другой таблицы?

Что-то типа такого select UserAliases.alias where UserAliases.userid=Participants.userid where Participants.ChatId=17

Вроде подразобрался

select alias from UserAliases where UserId=(select Participants.Userid from Participants where ChatId=17)

Но выводит только одно значение

@onegai ключевое слово для поиска нужной информации - JOIN. А если одно значение - посмотрите глазками, вполне может оказаться, что оно именно одно.

@onegai ключевое слово для поиска нужной информации - JOIN. А если одно значение - посмотрите глазками, вполне может оказаться, что оно именно одно.

нет, точно не одно. Было бы одно, я б не заморачивался запросом ? попробую с join, спасибо! ?

ЗЫ. Хотя ПГ достаточно умный, чтобы планы запросов с JOIN или подзапросом были идентичными.

select Alias from UserAliases, Participants where UserAliases.UserId=Participants.Userid and Participants.ChatId=17

Вот так получилось ? Вроде правильный результат выдает ?

ребятки, есть кейсы когда uuid как PK лучше не юзать?

читаю везде, говорят что работают превосходно, разве что весят чуть больше и джойнятся чуть дольше, и нельзя делать ORDER BY id;

Смысла просто не будет. Хотя его и так нет. Если они в тосте то индекс всё равно небольшой. Вот сравнение кончно и сохранение, уникальность будет дольше...

как бы сквозной запрос

Join

Akylai M: Добрый день всем , я извеняюсь за тупой вопрос но у меня стоит задача написать запрос ,для вывода сводной таблицы я раньше выводила подобное но на постгресс что то все время не получается Необходимо вывести количество транзакций за определенный период

Akylai M: пишу такой запрос он определяет лишь колисчество но вот по статусу но вотт функцию со временем сюда не могу довписать типо такого должно получиться

Где в запросе date?

Вот я не знаю кужа егу засунуть

Куда

этой книжки достаточно будет для нормальной работы с постгресом на реальных проектах? Или еще есть что прочитать? https://postgresql.leopard.in.ua/images/cover-62ab3a7e.jpg

@artnv я бы рекомендовал начать с курсов postgrespro: https://postgrespro.ru/education/courses

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

Pivot какой-нибудь? С кубами. Сложно короче

этой книжки достаточно будет для нормальной работы с постгресом на реальных проектах? Или еще есть что прочитать? https://postgresql.leopard.in.ua/images/cover-62ab3a7e.jpg

Вполне. Конечно, практический опыт никто не отменял, для принятии максимально правильного решения по имеющейся информации/знаниям.

этой книжки достаточно будет для нормальной работы с постгресом на реальных проектах? Или еще есть что прочитать? https://postgresql.leopard.in.ua/images/cover-62ab3a7e.jpg

А в пдф есть ?

да там она бесплатная еще и в пдф и в хтмл epub

Океюшки

Океюшки

https://postgresql.leopard.in.ua/

В большистве случаев решается на уровне приложения. Допустим под .NET есть мощный инструмент nreco, под python - pandas и т.д.

Подскажите, как поведет себя btree index, если будет много дубликатов Скажем такая таблица table chat(id bigserial, accountId int, name text) Если сделаю индекс по колонке accountId В случае поиска понятно, будет импрувмент, а при инсерте, апдейте, удалении базе прийдется проходить полностью по всем узлам с одинаковым значением? Имет ли смысл сделать индекс на две колонки (accountId, id)?

одно уникальное значение - один узел дерева

поэтому нет, не придется обходить все

одно уникальное значение - один узел дерева

Но там же не уникальные значения, а в индексе хранятся rowid с хипа?

но вы же спрашивали про дубликаты, или я не понял?

окей, я понял

ладно, утвеждать не возьмусь, может, коллеги подскажут

но вы же спрашивали про дубликаты, или я не понял?

Да, я имею в виду не уникальный индекс, т.е. Много записей для каждого аккаунта

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

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

Спасибо, наверно пока не буду сильно париться по этому поводу

Есть таблица такая: id uuid PK seller_id uuid REFERENCES seller(id) status state DEFAULT 'new' -- state - кастомный тип ENUM ... Можно ли как-то сделать такой констрейнт, чтобы в таблице могла быть только одна запись со status = 'new' для каждого seller_id. При этом, остальные status, например 'send', 'paid' и т.д., может быть много для одного и того же seller_id?

Есть таблица такая: id uuid PK seller_id uuid REFERENCES seller(id) status state DEFAULT 'new' -- state - кастомный тип ENUM ... Можно ли как-то сделать такой констрейнт, чтобы в таблице могла быть только одна запись со status = 'new' для каждого seller_id. При этом, остальные status, например 'send', 'paid' и т.д., может быть много для одного и того же seller_id?

UNIQUE INDEX .... On orders(seller_Id) WHERE state = 'new'

разве это не создаст уникальный индекс по всему столбцу state?

ERROR: S client not available

сейчас попробую, спасибо

сейчас попробую, спасибо

Должно сработать https://www.postgresql.org/docs/9.6/static/indexes-partial.html

Example 11-3. Setting up a Partial Unique Index

ну я пока DDL описываю, данными не заливал, т.к. там куча REFERENCES. но в ддлке прописалось, и я уже натыкался на такой вариант, но по тупости не увидел что там есть ON table(column)

так что думаю будет работать :)

ну я пока DDL описываю, данными не заливал, т.к. там куча REFERENCES. но в ддлке прописалось, и я уже натыкался на такой вариант, но по тупости не увидел что там есть ON table(column)

Фишка не в on, a в WHERE

да, я уже понял)

этой книжки достаточно будет для нормальной работы с постгресом на реальных проектах? Или еще есть что прочитать? https://postgresql.leopard.in.ua/images/cover-62ab3a7e.jpg

Только реальный опыт чему-то учит. Книжки - это для общего развития.

этой книжки достаточно будет для нормальной работы с постгресом на реальных проектах? Или еще есть что прочитать? https://postgresql.leopard.in.ua/images/cover-62ab3a7e.jpg

Прекрасная (fine) документация к Постгресу, главы 1-13, главы 37, 38 и 42 (для версии 10) - и можно приступать к любому проекту. Остальные знания будут появляться с опытом.

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

урсы крутые. почитай там презы хотя б.

но там много практики полезной

именно чтобы быстро войти в тему

этой книжки достаточно будет для нормальной работы с постгресом на реальных проектах? Или еще есть что прочитать? https://postgresql.leopard.in.ua/images/cover-62ab3a7e.jpg

Книга так себе, IMHO. Я вообще хороших и актуальных на русском не видел. Вместо книг лучше с документации начать.

Только реальный опыт чему-то учит. Книжки - это для общего развития.

В программировании-то? Ну-ну. ;)

где ожидать ошибки - да

Да, в программировании.

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

Ну а я бы сказал — наборот. Отрасль в целом переполнена недоучками-"практиками", IMHO.

Ну а я бы сказал — наборот. Отрасль в целом переполнена недоучками-"практиками", IMHO.

А учёных теоретиков в отрасли вообще не видно.

И толк от них околонулевой.

вполне есть толк, только они компиляторы всякие пишут

вполне есть толк, только они компиляторы всякие пишут

Теоретики ничего не пишут. Они только говорят и поучают.

Эээ... что именно вы называете "отраслью", в таком случае?

Ну и читают "труды" друг друга. И ходят вокруг дуба по цепи ))

Подскажите, как поведет себя btree index, если будет много дубликатов Скажем такая таблица table chat(id bigserial, accountId int, name text) Если сделаю индекс по колонке accountId В случае поиска понятно, будет импрувмент, а при инсерте, апдейте, удалении базе прийдется проходить полностью по всем узлам с одинаковым значением? Имет ли смысл сделать индекс на две колонки (accountId, id)?

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

Эээ... что именно вы называете "отраслью", в таком случае?

Реальный результат разработки. У теоретиков нет реальных результатов. У них одни бла-бла.

Теоретики ничего не пишут. Они только говорят и поучают.

Кто был соавтором реализации SSI в PostgreSQL, вы не в курсе? Без этой "бесполезной теории" PostgeSQL до сих пор был бы не-ACID СУБД (как Oracle). И вообще, многие "теоретики" много чего написали (в смысле программ), кстати, но мы их любим не только за это. :)

Реальный результат разработки. У теоретиков нет реальных результатов. У них одни бла-бла.

вот не прав совсем

Подскажите, как поведет себя btree index, если будет много дубликатов Скажем такая таблица table chat(id bigserial, accountId int, name text) Если сделаю индекс по колонке accountId В случае поиска понятно, будет импрувмент, а при инсерте, апдейте, удалении базе прийдется проходить полностью по всем узлам с одинаковым значением? Имет ли смысл сделать индекс на две колонки (accountId, id)?

лучше поискать вторую колонку всё-таки, по которой будут селекты.