?

Log in

No account? Create an account

...

или внеочередные заметки


[sticky post]Случайные фотки
trekking, Himalaya
obartunov
Этот пост - моя фоторамка. Весь дневник так или иначе построен вокруг моих впечатлений, которые я попытался сохранить в своих фотографиях. Можно подписаться на rss.
Oleg Bartunov - View my most interesting photos on Flickriver
ненужные подробности для историиCollapse )
Tags:

Вершины крупным планом
trekking, Himalaya
obartunov
Решил собрать здесь вершины гор, снятые мною крупным планом. Буду потихоньку добавлять, поэтому пусть этот пост повисит немного. Пока добавил фотографии из района Эвереста.
Upd. Добавил фотографии из Пакистана.

Read more...Collapse )

Partial TOAST decompression for jsonb
trekking, Himalaya
obartunov
Inspired by commit support for partial TOAST decompression
"When asked for a slice of a TOAST entry, decompress enough to return the slice instead of decompressing the entire object."

I and Nikita Glukhov made a quick experiment to see how jsonb could get benefit from this commit. The idea is simple, let's short values (more valueable) stores before long one. Currently, access time is independent on key, but with support of partial decompression we can get benefit for front keys.

Since jsonb stores values of keys in sorted (by key) order, we generate values depending on key name.

{
  "key1": "aaaa", /* 4 ^ 1 */
  "key2": "aaaaaaaaaaaaaaaa", /* 4 ^ 2 = 16 */
  ...
  "key10": "aaa ... aaa" /* 4 ^ 10 = 1M */
}

create table t(jb jsonb);
insert into t select (
  select jsonb_object_agg('key' || i, repeat('a', pow(4, i)::int)) from generate_series(1,10) i
) from generate_series(1, 1000);



We applied the partial decompression for '->' operator and tested performance with this simple query
select jb->'key1' from t;


The result is as expected - access time depends on a key:
key1-key5   key7    key8     key9     key10
  10 ms     48 ms   152 ms   548 ms   2037 ms

Access time for non-optimized operator '->>' is the same for all keys and roughly is 2000 ms.

So, this is what we can get for now. Ideally we want to have access time for all keys equal for time of accessing the first (fastest) key, currently we have the opposite.

I hope TOAST will be improved and we could decompress any slice using data type specific algorithm.
Tags: , ,

Generate less WAL during GiST, GIN and SP-GiST index build
trekking, Himalaya
obartunov
"Instead of WAL-logging every modification during the build separately,
first build the index without any WAL-logging, and make a separate pass
through the index at the end, to write all pages to the WAL. This
significantly reduces the amount of WAL generated, and is usually also
faster, despite the extra I/O needed for the extra scan through the index.
WAL generated this way is also faster to replay."

Идея простая, уже не помню, кому она пришла в голову,помню что родилась она когда мы мучались с большим трафиком при создании RUM-индекса, трафик там гигантский был (https://obartunov.livejournal.com/189690.html), потому что для расширения используется generic WAL, который достаточно тупой и не понимает смещения. Поэтому для RUM мы так и сделали, пишем wal специальным проходом после создания индекса (http://www.sai.msu.su/~megera/postgres/talks/fosdem-fts-2016.pdf, слайд #26). Теперь так же делается и для GiST, GIN и SP-GiST.

Для демонстрации пользы патча (gin индекс) я использовал базу imdb в json формате, можно скачать у меня для экспериментов http://www.sai.msu.su/~megera/postgres/files/imdb-27-01-2017-json.dump.gz

\dt+ imdb
List of relations
Schema | Name | Type | Owner | Size | Description
--------+------+-------+----------+---------+-------------
public | imdb | table | postgres | 2938 MB |
(1 row)
SELECT pg_current_wal_lsn();
pg_current_wal_lsn
--------------------
1/2E8B448
(1 row)
create index on imdb using gin(jb jsonb_path_ops);
CREATE INDEX
Time: 205115.236 ms (03:25.115)
SELECT pg_current_wal_lsn();
pg_current_wal_lsn
--------------------
1/CAFCB638
(1 row)
SELECT pg_size_pretty(pg_wal_lsn_diff('1/CAFCB638','1/2E8B448'));
pg_size_pretty
----------------
3201 MB
(1 row)

Аналогично сделал для версии после этого коммита:

reate index on imdb using gin(jb jsonb_path_ops);
CREATE INDEX
Time: 133554.225 ms (02:13.554)

SELECT pg_size_pretty(pg_wal_lsn_diff('0/CA9EC558','0/B13C4070'));
pg_size_pretty
----------------
406 MB
(1 row)


Выводы:
Трафик уменьшился в 8 раз, что привело к уменьшению времени построения индекса с 200 сек для 133 сек, ну очень полезный комит !
Tags: , ,

Долина Хинку: Млечный Путь
trekking, Himalaya
obartunov
Есть такое понятие "закрыть гештальт", для меня с 2013 года перевал Амфу Лабста с Севера и был таким гештальтом, когда мы из-за сильного ветра в начале января 2013 года не пошли на перевал (Фотоальбом Nepal-2012). Этот перевал обычно ходят с юга и он достаточно трудный, его высота выше 5800 м, требуются кошки и веревки. С Севера он труднее. И вот весной 2018 года я это сделал (Фотоальбом Nepal-2018). После перевала в одной ночевке находится озеро Seta Pokhari, сбоку от гиганта Chamlang. От этого озера в дне пути находится базовый лагерь Mera пика на перевале Mera La.У этого озера я и снял ночью Млечный Путь с Марсом, Сатурном и Юпитером, но больше всего меня восхитила Южная Корона, которую я никогда ранее не видел. В целях изучения звездного неба я сгенерил карту на нашем сайте www.astronet.ru, пользуйтесь ! Картинки кликабельные и откроются в новом окне.


Milky Way, Seta Pokhari, Hinku Valley





Звездная карта от Астронета(откроется в новом окне)

.

Read more...Collapse )

Письмо чиновнику про OSS в России (12 мая 2005)
trekking, Himalaya
obartunov
Subject: some comments to your talk at OSS forum Russia 2005

Доброе время суток,

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

Read more...Collapse )

Неопубликованное интервью журналу "Мир ПК" про Астронет
trekking, Himalaya
obartunov
В 2005 году к создателям сайта Astronet.ru обратился журнал "Мир ПК" с идеей рассказать про создание сайта, планы. Я, Миша Прохоров ответили на вопросы, а Женя Родичев стормозил, потом мы все были очень занятые и печать не состоялась. Я раскопал архив на нашем SUN и нашел вот это интервью:

Read more...Collapse )
Tags:

6 миллиона хитов на фликре !
trekking, Himalaya
obartunov
Tags:

Оставить "след" в постгресе
trekking, Himalaya
obartunov
1. Полный список задач с описаниями для некоторых доступен https://docs.google.com/document/d/1wzDlMF7NkZZC4Kp6m6KRaYeaSYyU6tKvRkDUlKOyCjs/

2. Список ресурсов для начинающих разработчиков PostgreSQL
https://obartunov.livejournal.com/195274.html

3. Решить задачу - это написать код, тесты (функциональные, производительность), документацию

Задачи, которые я предлагаю для решения. Трудность: (1-5), 1 очень легкая.

1 (1). Добавить поддержку всех встроенных типов данных для BLOOM индекса
https://obartunov.livejournal.com/201027.html
2.(1) Перенести hstore_ops в contrib/hstore
https://github.com/postgrespro/hstore_ops
3.(2) Сделать сравнение в GIN opclass’ах для массивов без collation’а

4.(2) N-gram словарь для FTS (см. show_trgm() в contrib/pg_trgm)

5. (4) Сделать, чтобы GIN заработал как EXCLUSION CONSTRAINT

6. (3) Улучшить сигнатурный поиск в GiST

7. (4) Добавить поддержку GIN для contrib/ltree

8. (4) Добавить в RUM индекс opclass для поиска ближайших соседей.
Практический пример: Найти ближайший ресторан с названием, удовлетворяющий tsquery
Для этого надо добавить хранение point в дополнительной информации и написать соотв. opclass.

9. (3) Abbreviated keys для jsonb

10. (3) HTML parser for text search

11. (5) Конфигурируемый парсер для FTS - очень важная архитектурная задача

12. (5) Поддержка tf*idf ранжирования для FTS

13. (5) Approximated aggregates - неточное вычисление агрегатов.
1. Ограничиваем время выполнения запроса, получаем ответ и оценку ошибки
2. Задаем ошибку, время любое

14. (1) UNNEST(tsquery), см. функцию UNNEST(tsvector), только надо добавить флаг - слово или операция

select * from unnest('one:1 two:3a'::tsvector);
lexeme | positions | weights
--------+-----------+---------
one | {1} | {D}
two | {3} | {A}
(2 rows)


15. (1) Разобраться с tf*idf ранжированием, потестировать качество и производительность
https://github.com/obartunov/setrank
Tags: ,

Bloom index for bigint
trekking, Himalaya
obartunov
Bloom index by default works for int4 and text, but other types with hash function and equality operator could be supported. Just use opclass interface, for example, for type bigint


CREATE OPERATOR CLASS bigint_ops
DEFAULT FOR TYPE bigint USING bloom AS
OPERATOR 1 =(bigint, bigint),
FU>CTION 1 hashint8(bigint);


Now, you can build bloom index for bigint data type.

PS.
Data types, which could be supported by bloom index.

SELECT oc.opcintype::regtype, p.amproc FROM pg_opclass oc
JOIN pg_amproc p ON p.amprocfamily = oc.opcfamily
WHERE oc.opcmethod = 405 AND oc.opcdefault AND p.amprocnum = 1
AND p.amproclefttype = oc.opcintype AND p.amprocrighttype = oc.opcintype;
Tags: , ,