Size: a a a

pgsql – PostgreSQL

2020 July 15

N

Nikolay in pgsql – PostgreSQL
Sergey Bubnov
Всем привет.  Подскажите, почему PG ведет себя следующим образом. Есть таблица с 12кк записей. Если долго не обращаться к этой таблице, то первый запрос работатет очень долго (20-30 сек), при это explain analyze показывает, что используются идексы. А следующее обращение к этой таблице уже работает быстро, даже если изменить параметры для поиска (дальше все запросы по 100-200мс идут)
20-30 секунд.там джойны?
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Twilight Angelo
с цифры начинать нельязя, зато с буквы можно, "-" используй сколько хочешь а вот на "." уже жалуется)
> с цифры начинать нельязя

# CREATE DATABASE "1";
CREATE DATABASE


>  а вот на "." уже жалуется)

# CREATE DATABASE "O.RLY";
CREATE DATABASE


> может знает кто

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

DP

Dmitry Podkopaev in pgsql – PostgreSQL
Подскажите пожалуйста для чего нужны транзакции?
источник

D

Denisio in pgsql – PostgreSQL
набрал в гугле "для чего нужны транзакции" первая страница результата даёт исчерпывающую инфу
источник

DP

Dmitry Podkopaev in pgsql – PostgreSQL
я так понимаю для премещения данных из одной таблицы в другуюю?
источник

N

Nikolay in pgsql – PostgreSQL
Dmitry Podkopaev
я так понимаю для премещения данных из одной таблицы в другуюю?
Вы почитайте про ACID.
источник

D

Denisio in pgsql – PostgreSQL
ты ознакомился с результами поиска ? там значительно подробнее всё написано
источник

SB

Sergey Bubnov in pgsql – PostgreSQL
Nikolay
20-30 секунд.там джойны?
нет, там сортировки и where  только
источник

N

Nikolay in pgsql – PostgreSQL
Sergey Bubnov
нет, там сортировки и where  только
если возвращается при этом немного записей. скажем сотини или тысячи, то это скорее неподходящий индекс, чем подходящий
источник

SB

Sergey Bubnov in pgsql – PostgreSQL
Nikolay
если возвращается при этом немного записей. скажем сотини или тысячи, то это скорее неподходящий индекс, чем подходящий
кстати возможно. Там даже limit 50 стоит. Однако explain analyze показывает что используется  scan index ....
источник

ДМ

Дмитрий Матвеев... in pgsql – PostgreSQL
Sergey Bubnov
Всем привет.  Подскажите, почему PG ведет себя следующим образом. Есть таблица с 12кк записей. Если долго не обращаться к этой таблице, то первый запрос работатет очень долго (20-30 сек), при это explain analyze показывает, что используются идексы. А следующее обращение к этой таблице уже работает быстро, даже если изменить параметры для поиска (дальше все запросы по 100-200мс идут)
там только запись? Или еще есть обновления?
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Вроде же разобрались уже с этим вопросом — потому что кеширование.
Нет?
источник

SB

Sergey Bubnov in pgsql – PostgreSQL
Yaroslav Schekin
Вроде же разобрались уже с этим вопросом — потому что кеширование.
Нет?
После добавления оперативки, я отпишу результат)
источник

N

Nikolay in pgsql – PostgreSQL
Yaroslav Schekin
Вроде же разобрались уже с этим вопросом — потому что кеширование.
Нет?
кешерование может скрывать проблему. понятно, что если все в кэш загнать, то будет быстрее, но может можно и так приемлимой скорости достичь
источник

ДМ

Дмитрий Матвеев... in pgsql – PostgreSQL
Ну у меня есть версия, что если обновлений много было. То при select много очисток страниц происходит при таком количестве записей. Из за этого долго
источник

SB

Sergey Bubnov in pgsql – PostgreSQL
Дмитрий Матвеев
там только запись? Или еще есть обновления?
добавление/удаление (обновления нет, и если и будет то очень разово)
источник

TA

Twilight Angelo in pgsql – PostgreSQL
Yaroslav Schekin
> с цифры начинать нельязя

# CREATE DATABASE "1";
CREATE DATABASE


>  а вот на "." уже жалуется)

# CREATE DATABASE "O.RLY";
CREATE DATABASE


> может знает кто

Опять-таки, никаких ограничений, кроме длины, я что-то не вижу.
хмммм, мне мнэджер на даёт регать, завтра у админов поузнаю. на сколько я понял зависит от какого-то параметра как можно именовать а как нельзя
источник

N

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

N

Nikolay in pgsql – PostgreSQL
так можно дойти до того, что всю базу надо в кеше держать.
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Sergey Bubnov
После добавления оперативки, я отпишу результат)
А Вы совету https://t.me/pgsql/238128 последовали (вообще в плане tuning, я имею в виду)?
Вам вообще стоит разобраться, можно ли "горячие" данные как-то вместить в shared_buffers (либо увеличить их и выполнить прочий tuning, либо как-то избежать чтения каких-то данных).
источник