Postgre. "Администрирование" через консоль.

[bosh]

Postgre. "Администрирование" через консоль.

Собственно в mysql всё просто mysql -u -p ...
далее show proceslist и kill особо злостные селекты.

А в Postgre SQL есть что-нибудь подобное?
1. Ну в смысле можно ли зайти в консоль где можно делать разные селекты?
2. Можно ли из неё посмотреть какие SELECT выполняются?

 

[YRusinov]

Попробуй psql <твоя база>

 

[Sad Spirit]

Автор оригинала: bosh
Собственно в mysql всё просто

Собственно в PostgreSQL тоже не очень всё сложно, но рекомендуется RTFM.

А в Postgre SQL есть что-нибудь подобное?
1. Ну в смысле можно ли зайти в консоль где можно делать разные селекты?

Консоль, как уже было отмечено, называется psql

2. Можно ли из неё посмотреть какие SELECT выполняются?

Можно:

SELECT * FROM pg_stat_activity;

Для того, чтобы SELECT'ы были видны, надо включить stats_command_string в postgresql.conf

 

[Alexandre]

psql <имя БД> - это если имя пользователя совпадает с логином
или
psql -U <логин> <имя БД>
Пароль: <вводим пароль>

# - появляется приглашение работать в консоли или посылают на...

 

[bosh]

Прописал в конфиге переменную.

stk1=# SELECT * FROM pg_stat_activity;
datid | datname | procpid | usesysid | usename | current_query | query_start
-----------+---------+---------+----------+---------+---------------+-------------------------------
112118743 | stk1 | 32158 | 100 | stk | <IDLE> | 2006-03-17 11:57:29.54649+03


А что сделать что бы вместо <IDLE> было бы тело запроса? такое вообще можно сделать ?
В mysql (если память не изменяяю) это делалось
show fulprocesslist;
Тут есть такая штука?

-~{}~ 17.03.06 12:53:

Странная весчь. Иногда особо долгоиграющие запросы пишутся. Видимо <idle> это когда нету запросов
И кстати в mysql пишется время выполения запроса. В постгре такое можно где-нибудь настроить?
(при запросах из консоли)

 

[Sad Spirit]

Автор оригинала: bosh
И кстати в mysql пишется время выполения запроса. В постгре такое можно где-нибудь настроить?
(при запросах из консоли)

Нахрена? Меряться с коллегами у кого быстрее?

Если есть проблемы с быстродействием конкретного запроса, то есть команда EXPLAIN ANALYZE, которая покажет, среди прочего, и время выполнения.

-~{}~ 17.03.06 19:23:

Да, а что касается pg_stat_activity, то там проявляются фактически только долго выполняющиеся запросы. Почему так --- см. документацию, близкий к тексту её пересказ здесь --- за отдельные деньги.

 

[bosh]

да да. Уже поняли.
Нет. Совсем не мерится с колегами. С целью особо долгие запросы выциплять. И их анализировать либо мочить.

Вот тут у нас табличка на несколько млн записей.
Делаем
select id,field1 from table where id>5000000 order by id limit 50;
Такой запрос выполняется долго довольно - десятки секунд.
Знающие колеги вкурившие мануал порекомендовали REINDEX и VACUM ANALIZE.

Я конечно всё забекапил, но скажите я так не убью собсно сервер нафик? И, если я правильно понимаю таблица будет залочена на время выполнения указанных действий?

 

[Sad Spirit]

Автор оригинала: bosh
Вот тут у нас табличка на несколько млн записей.
Делаем
select id,field1 from table where id>5000000 order by id limit 50;
Такой запрос выполняется долго довольно - десятки секунд.

Что говорит команда EXPLAIN?
Каков тип поля id и версия сервера?

Знающие колеги вкурившие мануал порекомендовали REINDEX и VACUM ANALIZE.

Я конечно всё забекапил, но скажите я так не убью собсно сервер нафик? И, если я правильно понимаю таблица будет залочена на время выполнения указанных действий?

Естественно нет. При выполнении REINDEX таблица будет залочена, при выполнении VACUUM --- нет. Но REINDEX, кстати, здесь вряд ли нужен.

 

[neko]

Нет. Совсем не мерится с колегами. С целью особо долгие запросы выциплять. И их анализировать либо мочить.

включи сохранение долгих запросов в лог.

 

[bosh]

А это как ?
И что в логах то будет. Запросов то много ведь. И "убийственных" то несколько всего.

 

[neko]

см. log_min_duration_statement

 

[bosh]

[SQL]
SELECT "id","msisdn","news_id","timestamp" FROM "Clients_log" WHERE "id" > 5511531 LIMIT 5;
[/SQL]

- Выполняется 25 секунд.

explain SELECT "id","msisdn","news_id","timestamp" FROM "Clients_log" WHERE "id" > 5511531 LIMIT 5;
QUERY PLAN
-----------------------------------------------------------------------------
Limit (cost=0.00..17.88 rows=5 width=39)
-> Seq Scan on "Clients_log" (cost=0.00..102994.95 rows=28804 width=39)
Filter: (id > 5511531)

Я к сожалению не обучен читать такие эксплейны. Те что говорит SQL навигатор Оракловый мне куда привычнее.


CREATE TABLE "Clients_log"
(
id int8 NOT NULL DEFAULT nextval('public."Clients_log_id_seq"'::text),
msisdn varchar(15) NOT NULL,
news_id int8 NOT NULL,
"timestamp" timestamp NOT NULL,
CONSTRAINT "PK_Clients_log" PRIMARY KEY (id)
)
WITH OIDS;

Основная проблем в том что я не большой специалист по Postgre как наверное уже понятно. Я лишь осуществляю миграцию с Postgre на Oracle. Но вот с такой скоростью выполнения запросов есть мысли что мигрировать я буду до пенсии
Сейчас запущу VACUUM FULL ANALYZE "Clients_log"; Интересно что это даст


Оригинально ведет себя Postgre.
VACUUM FULL ANALYZE "Clients_log"; -
и пока он делается - unable to Connect to Postgre ^))
Эффекта никакого.

-~{}~ 20.03.06 11:59:

PostgreSQL 7.4.7 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC) 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)

Если это хоть как-то поможет

-~{}~ 20.03.06 18:24:

Очень неожиданное решение для меня по крайней мере:
http://www.sql.ru/forum/actualthread.aspx?tid=273438
Кому интересно в чем было дело.

 

[neko]

bosh
> Очень неожиданное решение для меня по крайней мере:

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

 

[Sad Spirit]

Автор оригинала: bosh
Оригинально ведет себя Postgre.
VACUUM FULL ANALYZE "Clients_log"; -
и пока он делается - unable to Connect to Postgre ^))
Эффекта никакого.

-~{}~ 20.03.06 11:59:

PostgreSQL 7.4.7 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC) 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)

Если это хоть как-то поможет

В общем доктор прописывает 20 уколов документации внутримышечно и апгрейд до версии 8.x