Панель питания conky + dzen2 + xmonad

На выходных продолжил копать conky, dzen2 и xmonad и сделал пару панелек для верхнего бара. Сегодня расскажу про панель питания.

Задача была следующая:

- информировать от сети или от батареи сейчас питание;
- процент зарядки батареи с визуализальным индикатором;
- оставшееся время работы батареи, если работает от питания.

Вот так это выглядит:

Read more »

Опять про отступы в sql-mode Emacs

Сделал не большую правку в конфиге для sql-mode. Теперь когда просто нажимаешь "TAB" всегда делается отступ в 4 пробела, а когда нажимаешь "C-j" делается переход на новую строку с относительным отступом там где надо.

Проверяем в транзакции мы или нет

Надо проверить была ли транзакция открыта явно, т.е. с помощью BEGIN, и находится ли наш бэкенд в ней, т.е. она ещё до сих пор не закрыта. Решением будет вот такой не большой запрос:

SELECT xact_start < query_start
FROM pg_stat_activity
WHERE procpid = pg_backend_pid();

Postgres участвует в Google Summer of Code 2010

Перевод Postgres participating in Google Summer of Code 2010 с PostgreSQL: News

Пост от 2010-03-20
Автор xzilla@users.sourceforge.net

Я счастлив сообщить что Postgres был выбран для участия в программе Google Summer of Code этого года. В следующую пару недель мы будем утверждать наставников; если вы работаете над Postgres и хотели бы взять под своё начало ученика, сообщите мне об этом, чтобы мы могли вас записать. Если вы ученик и хотели бы работать над Postgres, присылайте свои предложения. Набор учеников начнётся 29 марта, т.ч. мы бы хотели чтобы наставники были готовы, и чтобы студенты обсудили с разработчиками Postgres свои предложения. Если у кого-то есть вопросы, пишите мне на email или найдите меня в irc.

Полезные ссылки для Postgres GSoC:

Our ideas page for GSoC

Our loose attempt at organization

Our Postgres page on the GSoC site

Users Guide to GSoC

Спасибо всем, буду ждать ещё одного интересного года c GSoC и надеюсь что вам понравится.

Блокировки по процессам

Запрос выводит информацию по процессам, для каждого из которых добавляется информация по блокировкам, представляющая собой признак удерживания/ожидания блокировок и их количество. Порядок определяется этими признаком и количеством, т.е. сверху будут удерживающие наибольшее количество блокировок процессы.

Удобно смотреть с \x

SELECT
granted, -- удерживает (t)/ожидает (f)
count(1) AS locks, -- ^^^ количество блокировок
pid, -- pid
now() - xact_start AS xact_age, -- длительность транзакции
now() - query_start AS query_age, -- длительность запроса
current_query -- текущий запрос
FROM
pg_locks AS l
LEFT JOIN pg_stat_activity AS a ON
pid = procpid
GROUP BY 1, 3, 4, 5, 6
ORDER BY 1 DESC, 2 DESC
-- ORDER BY 4 DESC
LIMIT 100;

В ожидании 9.0 (8.5) - Информация об использовании буферов в EXPLAIN

Перевод Waiting for 8.5 – buffers info for explain с select * from depesz;

(В январе 2010 г. команда разработчиков решила, что следующая версия PostgreSQL будет нумероваться 9.0, а не 8.5)

Сегодня речь пойдёт о маленьком, но (по крайней мере для меня) действительно полезном патче. Принял его 15 декабря Robert Haas, а сделал Itagaki Takahiro:

Добавляет опцию EXPLAIN (BUFFERS) для отображения статистики
использования буферов.

Патч также убирает эту статистику из вывода track_counts, т.к. EXPLAIN
(или глобальная статистика) теперь считается лучшим местом для такой
информации.

Itagaki Takahiro, проверено Euler Taveira de Oliveira.

Read more »

В ожидании 9.0 (8.5) - Агрегаты с упорядочиванием

Перевод Waiting for 8.5 – ordered aggregates с select * from depesz;

(В январе 2010 г. команда разработчиков решила, что следующая версия PostgreSQL будет нумероваться 9.0, а не 8.5)

15 декабря Tom Lane применил патч от Andrew Gierth (aka RhodiumToad), добавляющий интересную возможность:

Поддержка ORDER BY в агрегатных функциях, наконец-то не хак-решение того в каком порядке значения будут агрегироваться. На ряду с этим снимается ограничение использования DISTINCT в агрегатах с одним и только одним аргументом.

Возможно стоит упомянуть о изменении в поведении: ранее agg(DISTINCT x) всегда выкидывала null-значения. Теперь это происходит только тогда, когда transition-функция агрегата реализует это ограничение. Иначе null-значения обрабатываются так, как обычно делает DISTINCT, т.е. возвращается одна копия.

Andrew Gierth, проверено Hitoshi Harada

Read more »

Замечания к релизу 9.0

Перевод 9.0 Release Notes Done с Bruce Momjian's blog

(В январе 2010 г. команда разработчиков решила, что следующая версия PostgreSQL будет нумероваться 9.0, а не 8.5)

Суббота, 20 Марта 2010

Я закончил замечания к релизу 9.0, тут вы можете найти их онлайн. Конечно же к финальной версии там ещё будет много правок.

PL/pgSQL по умолчанию

Перевод Waiting for (9.0) 8.5 – PL/pgSQL by default с select * from depesz;

(В январе 2010 г. команда разработчиков решила, что следующая версия PostgreSQL будет нумероваться 9.0, а не 8.5)

18 декабря Bruce Momjian прменил очень важный, но относительно не большой патч:

Устанавливает язык PL/pgSQL по умолчанию.

Нет смысла показывать пример, т.к. сообщение говорит обо всём - начиная с новой версии язык PL/pgSQL будет доступен по умолчанию во всех базах.

Было время, когда пользователи отказывались от хранимых процедур в связи с тем, что у них не было ни какого PL/ языка, а его установка требовала прав суперюзера. Начиная с 8.3 уже не надо было быть суперюзером, чтобы установить доверительний (trusted) язык, т.о. проблема почти исчезла, но сейчас она просто переста существовать :)

Мониторинг активности

Возвращает текущую активность в БД. В начале отображает ожидающие процессы, затем остальные. В каждой группе записи выстраиваются в порядке убывания длительности транзакции.

Удобно смотреть с \x

SELECT
waiting, -- ждёт?
now() - xact_start AS xact_age, -- длительность транзакции
now() - query_start AS queru_age, -- длительность запроса
procpid, -- pid
current_query -- запрос
FROM
pg_stat_activity
WHERE xact_start IS NOT NULL
ORDER BY 1 DESC, 2 DESC;

В ожидании 9.0 (8.5) - Изменения в VACUUM FULL

Перевод Waiting for 8.5 – VACUUM FULL change с select * from depesz;

(В январе 2010 г. команда разработчиков решила, что следующая версия PostgreSQL будет нумероваться 9.0, а не 8.5)

Некоторое время назад Josh Berkus написал о возможных изменениях в VACUUM FULL. Теперь это воплотилось в жизнь. Под "теперь" я имею ввиду 6 января, когда Takahiro Itagaki применил свой патч:

Поддержка основанного на перезаписи полного вакуума как
VACUUM FULL. Традиционный VACUUM FULL был переименован в VACUUM
FULL INPLACE. Также добавлена опция -i, --inplace в vacuumdb для
FULL INPLACE ваккума.

Т.к. новый VACUUM FULL использует инфраструктуру от CLUSTER, мы
не можем использовать его для системных таблиц. VACUUM FULL для
них прозрачно преобразуется в VACUUM FULL INPLACE.

Itagaki Takahiro, проверено Jeff Davis и Simon Riggs.

Read more »

В ожидании 9.0 - Потоковая репликация

Перевод Waiting for 9.0 – Streaming replication с select * from depesz;

(В январе 2010 г. команда разработчиков решила, что следующая версия PostgreSQL будет нумероваться 9.0, а не 8.5)

Это очень важный функционал, возможность благодаря которой PostgreSQL сделал скачёк от 8.4 до 9.0. Патч разработан Fujii Masao и принят Heikki Linnakangas 15 января 2010.

Добавляет Потоковую репликацию (Streaming replication).

Включает два новых вида процессов postmaster-а - walsender и walreceiver. Walreceiver отвечает за соединение с главным сервером и передачу WALL данных на диск, в то время как walsender работает на главном сервере и передаёт клиенту WAL данные с диска.

Документация всё ещё нуждается в доработке, но основа уже есть. Возможно мы позже вынесем секцию касающуюся репликации в отдельную главу, также как и секцию о репликации на основе файлов. Это будет в отдельном патче, чтобы было понятно что добавлено/изменено. Этот патч также добавляет новую секцию в главу о FE/BE протоколе, касающуюся walsender/walreceivxer

Подняли версию каталога из-за двух новых функций pg_last_xlog_receive_location() и pg_last_xlog_replay_location() для мониторинга прогресса репликации.

Fujii Masao, с дополнительными правками от меня

Read more »

Небольшое предпочтение в sql-mode Emacs

В общем чуток кастомизации sql-mode. Я привык в SQL к отступам в 4-е пробела и мне нравится контроль над пробельными символами (мой пунктик).

В управляющем файле ставим загрузку конфигурации для разных sql:

~/.emacs:
(load "~/.emacs.d/sql.el")

В конфигурации sql:

~/.emacs.d/sql.el:
;; Minor modes
(add-hook 'sql-mode-hook 'whitespace-mode)

;; 4 spaces instead of tab
(add-hook 'sql-mode-hook
'(lambda ()
(setq indent-tabs-mode nil
tab-width 4
indent-line-function 'insert-tab)
(define-key sql-mode-map (kbd "C-j")
'(lambda()
(interactive)
(delete-horizontal-space t)
(newline)
(indent-relative-maybe)))))

Всё, теперь меня ничего не смущает, гут :)

Правка от 2010-03-26
Установил функцию общего отступа в обычную табуляцию:

indent-line-function 'insert-tab

И переопределил "C-j" с использованием относительного отступа где надо:

(define-key sql-mode-map (kbd "C-j")
'(lambda()
(interactive)
(delete-horizontal-space t)
(newline)
(indent-relative-maybe)))))

В ожидании 9.0 - размеры таблиц и индексов

Перевод Waiting for 9.0 – table and index sizes с select * from depesz;

(В январе 2010 г. команда разработчиков решила, что следующая версия PostgreSQL будет нумероваться 9.0, а не 8.5)

19 января Tom Lane применил замечательный патч:

Добавлены pg_table_size() и pg_indexes_size() более удобные надстройки над функцией pg_relation_size().

Bernd Helmle, проверил Greg Smith

Read more »

Настраиваем Emacs для работы с PostgreSQL

Да-да, в Emacs всё уже давно есть. Просто делаем M-x sql-postgres, он спрашивает базу+пользователя+хост, вводим пароль и получаем буфер-терминал *SQL*, где видим всем известный инструмент psql для работы с PostgreSQL.

Но, если получаем длинный вывод, то наблюдаем артефакты от less или more (или что у вас там по умолчанию в качестве пейджера). К тому же, если работаем напрямую из окна в sql-mode (что очень удобно, см. M-x describe-function RET sql-set-sqli-buffer RET), то наблюдаем эффект с множественными повторениями подсказки (prompt).

Как это пофиксить? Идея в том, чтобы отключить PAGER (программу, через которую psql пропускает свой вывод), и "подтюнить" подсказку (prompt) средствами самого psql с помощью переменной sql-postgres-options, предоставляемой sql-mode.

Создаём файл с настройками для PostgreSQL.

~/.emacs.d/postgresql.el:
;; In psql turn off pager usage and adjust prompts
(setq sql-postgres-options '("-P" "pager=off"
"-v" "PROMPT1=%n@%m:%> %~%R%#\n"
"-v" "PROMPT2="
"-v" "PROMPT3="))


Далее добавляем подгрузку этих настроек в .emacs и всё.

~/.emacs:
(load "~/.emacs.d/postgresql.el")

В ожидании 9.0 - string_agg (агрегируем строки)

Перевод Waiting for 9.0 – string_agg с select * from depesz;

(В январе 2010 г. команда разработчиков решила, что следующая версия PostgreSQL будет нумероваться 9.0, а не 8.5)

1 февраля Takahiro Itagaki применил патч от Pavel Stehule, который добавляет агрегат string_agg:

Добавляет агрегатные функции string_agg. Версия с одним аргументом конкатенирует входные значения в строку, с двумя аргументами то же самое, но ещё добавляет разделитель между элементами.

Патч от Pavel Stehule, проверен David E. Wheeler и мной.

Read more »

В ожидании 9.0 - дополнение к фреймам window функций

Перевод Waiting for 9.0 – extended frames for window functions с select * from depesz;

(В январе 2010 г. команда разработчиков решила, что следующая версия PostgreSQL будет нумероваться 9.0, а не 8.5)

12 февраля Tom Lane принял патч Hitoshi Harada:

Расширение набора опций фреймов поддерживаемых window функциями.

Патч позволяет фреймам начинаться с текушей строки (CURRENT ROW) (в режиме либо RANGE либо ROW), и также добавляет поддержку ROWS n PRECEDING и ROWS n FOLLOWING для начальной и конечной точек. (PRECEDING/FOLLOWING для RANGE ещё не готово - граматика работает, но это всё что пока есть)

Hitoshi Harada, проверено Pavel Stehule

Read more »

Получаем определения всех индексов указанных типов

Я использовал этот запрос при переводе gist-индексов на gin.

SELECT indexdef
FROM pg_indexes
WHERE indexdef ~ 'USING (gist|gin)';

CHAR(x) или VARCHAR(x) или VARCHAR или TEXT

Выдержка из CHAR(x) vs. VARCHAR(x) vs. VARCHAR vs. TEXT с select * from depesz;

Оригинальная статья исключительно полно отвечает на один из самых часто задаваемых вопросов о PostgreSQL - Что лучше/быстрее/компактнее CHAR(x) или VARCHAR(x) или VARCHAR или TEXT? Не буду приводить в этом посте полный перевод, а только лишь пару выдержек, т.к., скорее всего, подавляющее большинство читателей заинтересует только ответ без исследования.

Выводы из результатов тестирования:

1. Скорость create table, load data и create index - одинаковый результат для всех типов.


2. Поиск по полям этих типов тоже показал одинаковую скорость.


3. Для типов с ограничением по размеру, если вы не исключаете возможность его изменения в дальнейшем, то имеет смысл использовать TEXT+DOMAIN, т.к. в этом случае будет ShareLock, а не AccessExclusiveLock на таблицу.


4. Если хотите ругаться на превышение размера триггером или CHECK констрейнтом, CHECK даст выигрыш скорости примерно в 2 раза.

Заключение автора статьи (depesz-а):

• char(n) - занимает слишком много места когда имеем дела со значениями короче n, также может приводить к не ожиданным ошибкам из-за дополнения пробелами в конце, плюс проблемы с изменением ограничения размера.


• varchar(n) - проблематично менять ограничение размера на "живой" базе.


• varchar – тоже что и text.


• text – по моему мнению победитель, над (n) типами потому что у него нет их проблем, и над varchar т.к. своё собственное имя.

Мой же выбор - text, и CHECK, если нужно ограничить размер.

Некоторые полезные функции

Выводит NOTICE с указанным текстом в лог. Используется для мониторинга активности, отслеживания прогресса миграции, и т.д., в общем не в процедурах, где вызовы типа RAISE NOTICE не возможны.

CREATE OR REPLACE FUNCTION raise_notice(text)
RETURNS void AS
$BODY$
BEGIN
RAISE NOTICE '%', $1;
RETURN;
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE
COST 1;

Read more »

Скрипты psql, занятно и полезно

Перевод Scripting psql for Fun and Profit с David Fetter's blog

Вы можете определённо многое терять не применяя разные полезные возможности. psql принимает большое количество опций коммандной строки. Одна из супер полезных опций это -v, которую можно использовать как эквивалент \set. Например:

psql -1 -v ON_ERROR_STOP=1 -f script.psql

останавливает скрипт на первой ошибке и делает rollback вместо заполнения экрана горой связанных с первой ошибок от дальнейшего содержимого скрипта.

Определяем файлы таблицы и всех её индексов

Я столкнулся с этой задачей, когда необходимо было форсировать "поднятие" таблицы и её индексов в файловый кэш утилитой dd, но уверен найдутся и другие способы полезного прменения этого решения.

SELECT oid AS dboid
FROM pg_database
WHERE datname = 'database1';

SELECT relfilenode AS tfile
FROM pg_class
WHERE relname = 'table1';

SELECT i.relfilenode AS ifile, i.relname
FROM
pg_class c
JOIN pg_index x
ON x.indrelid = c.oid
JOIN pg_class i
ON i.oid = x.indexrelid
WHERE c.relname = 'table1';

Путь к файлу таблицы выглядит так:

<path_to_pg_data>/base/<dboid>/<tfile>

А пути к индексам так:

<path_to_pg_data>/base/<dboid>/<ifile>