obartunov: (Default)
Many people already said, that the conference was great. Many thanks to organisers and sponsors ! I want to thank russian company 1C for support of my trip. I and Alexander Korotkov started our work on "Full-text search in PostgreSQL in milliseconds" after Pgcon conference in Ottawa, then I was a month in Karakorum nountains and it was too late to submit talk and get support, so I was looking for sponsorhip. I asked 1C company, which I and Teodor Sigaev know very well, and fortunately I got support. That was the first time I was supported by russian company !

Several important things about the conference I have in mind:

1. Index-only count - GiST and GIN currently doesn't support index-only scan, but could support index-only count, which is very useful. I talked with Dimitry Fontaine and it seems to convince him to work on this with Cédric Villemain for 9.3

2. Index-only scan for GiST, GIN. Currently, only btree indexes supports index-only scan, but some opclasses of GiST and GIN (btree_gist, btree_gin, points, range type,,,) could also support it ! So, we need more flexible infrastructure in pg_am. I talked with Jeff Davis and he is very interested in this, hope he can do something for 9.3.

3. I asked EntrepriseDB for support of our FTS, still no answer yet. It's vital for getting new improved FTS ready for 9.3. EDB supported me and Teodor in 2006 and it was great, since that we have FTS in PostgreSQL core, hope it will be able to do something for us this time.

4. Unfortunately, Peter got cold last dat and we didn't discussed our work on json, that's pity. The big problem with types in json is how to modify typmod to support types in json ! Our initial plan was to improve hstore to support hstore itself and arrays and then use this binary representation implement json. Now, we have more bigger problem, we need storage for json scheme and postgresql currently has no infrastructure for this. It's a separate big project and we'll think about it. Thanks Heroku for boat !

Just two pictures from Prague, I have much more on flickr, visit PGconf set, I'll publish more pictures there, I have hundreds of them !

PostgreSQL people in Hradčany, Prague

I have strong hands, so I was able to made this picture from the boat at low light ! Notice, blue seagull !

Blue seagulls, Prague
obartunov: (Default)
I'm going to the PGConEU in Prague ! Thanks to russian company 1c (it's really big company) for sponsorship !

I and Alexander Korotkov will present lightning talk "Fulltext search in PostgreSQL in milliseconds". I understand, that this topic needs more time, but we submitted the talk too late, sorry. I was in Karakorum, Pakistan the whole july. Anyway, we got really impressive results with prototype - on 6 mln records classified database we got 6-8 ms median search query time, total 41 mln search queries in 8 hours. We used real-life data from the biggest russian classified service and real search queries extracted from web-logs. We hope to discuss some implementation issues with developers and attract attention of sponsors. The latter is important, since the amount of development itself is big. We also need to pass through review nighmare :) There are not so much time remains for 9.3, by the way.

Abstract:

Fulltext search in PostgreSQL is well known by its powerfulness and extendability. However, there are two main reasons that prevent PostgreSQL fulltext search to be as fast as specialized solutions:

1) It's implemented inside ACID DBMS, that's why it have to support atomicity, concurrency, WAL etc. This issue is inevitable since we implement fulltext search inside object-relational DBMS, so it's both advantage and disadvantage.
2) Fulltext indexes are only used for document filtration, while ranking require fetching documents from heap. It reduces speed of high-selectivity queries processing. This disadvantage is not inevitable and it could be avoided by inclusion additional information into GIN-indexes.

This talk presents prototype of PostgreSQL patch allowing to store positional information into fulltext index and to use it for ranking. In this case ranking is performed using only index information without fetching documents from heap. It accelerates processing of high-selectivity queries in dozens of times. The work of prototype will be demonstrated on well known large databases.
obartunov: (Default)
Прогнал тесты сегодня на 9.2dev и сравнил результаты gist vs spgist. Данные сгенерены так:
select p.x, p.y into points  from 
( select  (0.5-random())*180 as x, random()*360 as y 
       from ( select generate_series(1,$NROWS) ) as t ) as p;


Краткий вывод такой, что spgist заметно быстрее gist до кол-ва записей 10млн, несмотря на бОльшее количество прочитанных блоков (в spgist процессору надо сильно меньше работать, чем для gist). Остается непонятной, почему spgist так не любит упорядоченные данные - кол-во блоков просто гигантское ! Для 15 млн записей spgist уже начинает проигрывать и связано это с каким-то аномальным количеством прочитанных блоков.

Разницy в количестве найденных записей Саша Коротков объяснил, надеюсь он поправит это. Дело в том, что в spgist происходит тупое сравнение координат, а в gist даже для листьев вызывается функция box_contained, которая сравнивает боксы с точностью до 10^-6, что и вызывает небольшое расхождение.

Время создания индексов gist и spgist не сильно отличается, так как gist значительно ускорился благодаря работе Саши Короткова. На прошлом pgcon в Канаде я показывал, что разница в скорости построения индекса достигала 2-3 раз в пользу spgist.

Надо будет еще прогнать тесты на реальных данных, ибо опыт показывает, что синтетические данные с равномерным распределением не очень хорошо отражают действительность.

test=# select testname, nrows, (endtime-begintime) as runtime, blks_accessed, totalrowsmatched from results order by nrows,testname;
         testname          |  nrows   |     runtime     | blks_accessed | totalrowsmatched 
---------------------------+----------+-----------------+---------------+------------------
 points ordered buffered   |    10000 | 00:00:00.128679 |        137324 |            40000
 points ordered spgist     |    10000 | 00:00:00.077355 |        229459 |            40000
 points unordered buffered |    10000 | 00:00:00.104902 |        136363 |            40000
 points unordered spgist   |    10000 | 00:00:00.078142 |        215500 |            40000
 points ordered buffered   |  1000000 | 00:00:24.090863 |        359825 |          4000004
 points ordered spgist     |  1000000 | 00:00:06.218287 |       4461765 |          4000000
 points unordered buffered |  1000000 | 00:00:07.345433 |        341337 |          4000004
 points unordered spgist   |  1000000 | 00:00:05.962986 |        693722 |          4000000
 points ordered buffered   | 10000000 | 00:03:32.921534 |       1082246 |         40000062
 points ordered spgist     | 10000000 | 00:01:32.837746 |      38326778 |         40000000
 points unordered buffered | 10000000 | 00:02:27.810558 |        981158 |         40000062
 points unordered spgist   | 10000000 | 00:01:23.498076 |       2195123 |         40000000
 points ordered buffered   | 15000000 | 00:05:14.415563 |       1386540 |         60000098
 points ordered spgist     | 15000000 | 00:05:54.343944 |      58132360 |         59999998
 points unordered buffered | 15000000 | 00:03:43.682043 |       1239613 |         60000098
 points unordered spgist   | 15000000 | 00:04:34.943515 |       2692225 |         60000000
obartunov: (Default)
Loose indexscan, implemented in MySQL provides effective way to select distinct valuse, since indexscan jumps on distinct values, without scanning all equal values. In case of not so many distinct values, the win may be very big. See an extreme (just 2 distinct values) example:
test=# \d tt
      Table "public.tt"
 Column |  Type   | Modifiers 
--------+---------+-----------
 id     | integer | 
Indexes:
    "tt_idx" btree (id)
test=# insert into tt(id)  select 0 from generate_series(1,1000000);
test=# insert into tt(id)  select 1 from generate_series(1,1000000);
test=# select distinct(id) from tt;
 id 
----
  0
  1
(2 rows)

Time: 481,807 ms
test=# with recursive t as 
(select min(id) as id from tt 
 union all 
 select (select min(id) from tt where id > t.id) from t where t.id is not null
) 
select id from t where id is not null 
 union all 
select null where exists (select * from tt where id is null);
 id 
----
  0
  1
(2 rows)

Time: 0,959 ms
test=#  select 481.807/0.959 as win_ratio; 
      win_ratio       
----------------------
 502.4056308654848801
(1 row)


500 times win ! PostgreSQL will not use index scan for the first query and this is a right choice !
obartunov: (Default)
Кому нужен show-case для убеждения ?

Вот статья "What Powers Instagram: Hundreds of Instances, Dozens of Technologies", где написано:

Most of our data (users, photo metadata, tags, etc) lives in PostgreSQL; we’ve previously written about how we shard across our different Postgres instances. Our main shard cluster involves 12 Quadruple Extra-Large memory instances (and twelve replicas in a different zone.)
.......


Сама статья весьма полезна будет архитекторам нагруженных систем, кстати. Основной вывод, который я считаю важным - это не изобретайте велосипед ! Я тут поигрался с Riak-ом и пообщался во Франции вживую с его разработчиками несколько дней и еще раз убедился, что все эти k-v NOSQL имеют довольно узкое применение и требуется очень хорошо понимать их ограниченность и матюрити :)
obartunov: (Default)
Начали писать документацию по SP-GiST, пока для хакеров. Хотелось бы до отлета (14 окт) успеть как-то написать и .юзеровскую с интерфейсами и примерами. Tom Lane написал, что хочет взяться за чтение патча, но без документации не начнет. Кстати, нашел фотографию 2006 года в Торонто, когда мы все увидели друг друга в первый раз после более 10-ти лет работы над постгресом ! Романтичное было время, однако ! Я и Федя Сигаев тогда представили наш полнотекстовый поиск, а после конференции укатили на Ниагарский водопад.

Oleg Bartunov and Tom Lane, Toronto

+1 )
obartunov: (Default)
Прочитал новость:

Lots of people have been asking the never ending question of when PostGIS is going to get on the band wagon and support KNN GIST like other GIST based types trigrams, full text search etc. Well it's happened in PostGIS 2.0 and now committed. More of the gory details at Indexed Nearest Neighbour Search in PostGIS. In short this will make point / point distance searches and rankings way way faster and help also with other distance searches by providing approximations to start with.
obartunov: (Default)
Сегодня погонял бенчмарки spgist-а на равномерно-распределенных случайных данных и расстроился - gist сильно быстрее spgist. Равномерные данные, конечно, оптимальны для гиста,ибо минимальный оверлап, но все-таки, непонятно, почему spgist медленнее.

Read more... )
obartunov: (Default)
Вот выдержка из статьи(Брюс Момжан натолкнул):

"If you're looking for the configuration for MySQL, you won't find it, either in the GUI or in the command line. That's because Apple has replaced it with PostgreSQL, another open source database. On one hand, this is an improvement, because PostgreSQL is considered to be more powerful than MySQL. But whereas Snow Leopard's Server Admin tool had GUI settings for MySQL, PostgreSQL is command line only in Lion Server."
obartunov: (Default)
Вот выдержка из статьи(Брюс Момжан натолкнул):

"If you're looking for the configuration for MySQL, you won't find it, either in the GUI or in the command line. That's because Apple has replaced it with PostgreSQL, another open source database. On one hand, this is an improvement, because PostgreSQL is considered to be more powerful than MySQL. But whereas Snow Leopard's Server Admin tool had GUI settings for MySQL, PostgreSQL is command line only in Lion Server."

www_fdw ?

Jul. 20th, 2011 07:00 pm
obartunov: (Default)
Ну, кто возьмется за написание www_fdw ? В 9.1 появилась кульная фича - SQL/MED. Вроде как Foreign Table уже занимаются и в 9.1 уже будет адаптер к файлам, а вот хорошо бы иметь адаптер к web-контенту, те, обращаться к вебу как к таблице.

www_fdw ?

Jul. 20th, 2011 07:00 pm
obartunov: (Default)
Ну, кто возьмется за написание www_fdw ? В 9.1 появилась кульная фича - SQL/MED. Вроде как Foreign Table уже занимаются и в 9.1 уже будет адаптер к файлам, а вот хорошо бы иметь адаптер к web-контенту, те, обращаться к вебу как к таблице.
obartunov: (Default)
Нет, никаких хинтов в постгресе нет, это я для красного словца написал :) А если серьезно, хочу рассказать про наше маленькое расширение, которое позволяет управлять планером, а именно, прятать от планера индексы. Часто бывает так, что вы лучше знаете, какой индекс надо бы использовать в данном конкретном запросе (я это не приветствую, планер обязан быть лучше !), или в ходе разработки надо тестировать разные индексы, при этом часто бывает занудно переделывать/удалять индексы, чтобы планер брал 'правильный' индекс. Чтобы этого не надо было делать, а просто подсовывать планеру нужный индекс и тестировать его, мы придумали расширение plantuner.
читайте его README )
obartunov: (Default)
Нет, никаких хинтов в постгресе нет, это я для красного словца написал :) А если серьезно, хочу рассказать про наше маленькое расширение, которое позволяет управлять планером, а именно, прятать от планера индексы. Часто бывает так, что вы лучше знаете, какой индекс надо бы использовать в данном конкретном запросе (я это не приветствую, планер обязан быть лучше !), или в ходе разработки надо тестировать разные индексы, при этом часто бывает занудно переделывать/удалять индексы, чтобы планер брал 'правильный' индекс. Чтобы этого не надо было делать, а просто подсовывать планеру нужный индекс и тестировать его, мы придумали расширение plantuner.
читайте его README )
obartunov: (Default)
Update: Я выложил слайды моего доклада на совещании.

CNews очень оперативно написали Российский астроном предложил стране национальную СУБД. В целом все правда (с неизбежными косячками), только почему-то про Федю мало написали, а ведь мы в паре с ним все и делали. Кстати, Федя Сигаев тоже работает в ГАИШ, а по совместительству помогает mail.ru. Почитал форум на CNews, нормальное такое обсуждение, в духе наших форумов, что еще на linux.org.ru напишут ! Здесь я попытаюсь ответить на несколько вопросов, чаще всего поднимающихся в форуме:

1. Я профессиональный астроном, закончил астрономическое отделение МГУ, всю жизнь работаю в ГАИШ (Государственный Астрономический институт МГУ).
Вот по этой ссылке на Google scholar можно подсчитать мой индекс цитирования (что-то около 1100). Для сравнения можно подставить другую фамилию, скажу, что это вполне приличный астрономический показатель.
2. IT занялся осознанно, поняв, что никакой умный дядюшка не придет со стороны и не сделает нам хорошо. Астрономия как никакая наука нуждается в СУБД, сетях, правильной популяризации (столько безграмотности сейчас !).
Вот часть наших выступлений, остальные можно найти в сети.
3. Попутно, IT дает мне возможность на нормальную жизнь - я смог вырастить 3 детей, путешествую, вижу разные страны, людей, играюсь с разными гаджетами ( а кто не любит) итд, что на мою зарплату научного сотрудника в 10890 чистыми невозможно.
4. Я не распильщик, я хочу, чтобы финансирование НПП, хотя бы в какой-то мере, не пропало даром ! А именно, воспитать боевую команду разработчиков, способных осуществлять поддержку 3-го уровня для PostgreSQL, которую считаю действительно лучшим кандидатом на национальную СУБД.
5. Национальная СУБД - это жупел, который понимают чиновники, так что можете продолжать хихикать. Однако, за этим стоит реальная работа, например, перевод документации на русский язык, книг, пособий, создание курсов, сертификации и всего того, что называется рынок труда для людей вокруг PostgreSQL, ибо без рынка все это не заживет.
6. Я не шаман, кстати. Я чистокровный калмык, рост 191 см,вес 81.5, осенью исполнится 52 года, всю жизнь занимаюсь спортом (волейбол, теннис, подводное плавание, бег, велосипед, горы). Желающие могут меня увидеть в Камергерском переулке (кафе Прайм) и пробежать 15-ку по Воробьевым горам. Волейболисты меня и так знают ! Неожиданно для себя занялся фотографией серьезно, несколько карточек даже опубликовали в Daily Telegraph и куче более мелких изданий, вот мои самые популярные фотографии по версии фликра.
7. Ближайшие планы - поступить младшего сына, выпустить SP-GiST, сходить в Гималайи.

Это Федя Сигаев и я в легендарной комнате на легендарном диване обсуждаем GiST.



А вообще, почитайте мой ЖЖ.
obartunov: (Default)
Update: Я выложил слайды моего доклада на совещании.

CNews очень оперативно написали Российский астроном предложил стране национальную СУБД. В целом все правда (с неизбежными косячками), только почему-то про Федю мало написали, а ведь мы в паре с ним все и делали. Кстати, Федя Сигаев тоже работает в ГАИШ, а по совместительству помогает mail.ru. Почитал форум на CNews, нормальное такое обсуждение, в духе наших форумов, что еще на linux.org.ru напишут ! Здесь я попытаюсь ответить на несколько вопросов, чаще всего поднимающихся в форуме:

1. Я профессиональный астроном, закончил астрономическое отделение МГУ, всю жизнь работаю в ГАИШ (Государственный Астрономический институт МГУ).
Вот по этой ссылке на Google scholar можно подсчитать мой индекс цитирования (что-то около 1100). Для сравнения можно подставить другую фамилию, скажу, что это вполне приличный астрономический показатель.
2. IT занялся осознанно, поняв, что никакой умный дядюшка не придет со стороны и не сделает нам хорошо. Астрономия как никакая наука нуждается в СУБД, сетях, правильной популяризации (столько безграмотности сейчас !).
Вот часть наших выступлений, остальные можно найти в сети.
3. Попутно, IT дает мне возможность на нормальную жизнь - я смог вырастить 3 детей, путешествую, вижу разные страны, людей, играюсь с разными гаджетами ( а кто не любит) итд, что на мою зарплату научного сотрудника в 10890 чистыми невозможно.
4. Я не распильщик, я хочу, чтобы финансирование НПП, хотя бы в какой-то мере, не пропало даром ! А именно, воспитать боевую команду разработчиков, способных осуществлять поддержку 3-го уровня для PostgreSQL, которую считаю действительно лучшим кандидатом на национальную СУБД.
5. Национальная СУБД - это жупел, который понимают чиновники, так что можете продолжать хихикать. Однако, за этим стоит реальная работа, например, перевод документации на русский язык, книг, пособий, создание курсов, сертификации и всего того, что называется рынок труда для людей вокруг PostgreSQL, ибо без рынка все это не заживет.
6. Я не шаман, кстати. Я чистокровный калмык, рост 191 см,вес 81.5, осенью исполнится 52 года, всю жизнь занимаюсь спортом (волейбол, теннис, подводное плавание, бег, велосипед, горы). Желающие могут меня увидеть в Камергерском переулке (кафе Прайм) и пробежать 15-ку по Воробьевым горам. Волейболисты меня и так знают ! Неожиданно для себя занялся фотографией серьезно, несколько карточек даже опубликовали в Daily Telegraph и куче более мелких изданий, вот мои самые популярные фотографии по версии фликра.
7. Ближайшие планы - поступить младшего сына, выпустить SP-GiST, сходить в Гималайи.

Это Федя Сигаев и я в легендарной комнате на легендарном диване обсуждаем GiST.



А вообще, почитайте мой ЖЖ.
obartunov: (Default)
На cnews выложили видео с моим выступлением на круглом столе «Свободное ПО: переход к реальным действиям», теперь когда деньги распилят, мне не будут говорить, что я молчал :) Вообще говоря, хотелось бы увидеть выступления чиновников.
obartunov: (Default)
На cnews выложили видео с моим выступлением на круглом столе «Свободное ПО: переход к реальным действиям», теперь когда деньги распилят, мне не будут говорить, что я молчал :) Вообще говоря, хотелось бы увидеть выступления чиновников.
obartunov: (Default)
В Тулузе нам пожаловались на медленный полнотекстовый поиск на базе 10 млн записей. Сели разбираться и обнаружили, что если использовать алиас для to_tsquery, чтобы было удобнее запрос писать, то постгрес выбирает неудачный план. Под катом я приведу тестовый пример на базе гео-данных для штатов, обратите внимание на разницу в количестве поднятых буферов. В моем конкретном примере разница по времени невелика, так как все помещается в памяти, но вы понимаете, что будет, если придется читать с диска, как у нашего клиента, у которого поиск залетал и он стал прыгать от счастья. Вывод: Пишите to_tsquery() в запросе вместо использования from to_tsquery q.

Read more... )
obartunov: (Default)
В Тулузе нам пожаловались на медленный полнотекстовый поиск на базе 10 млн записей. Сели разбираться и обнаружили, что если использовать алиас для to_tsquery, чтобы было удобнее запрос писать, то постгрес выбирает неудачный план. Под катом я приведу тестовый пример на базе гео-данных для штатов, обратите внимание на разницу в количестве поднятых буферов. В моем конкретном примере разница по времени невелика, так как все помещается в памяти, но вы понимаете, что будет, если придется читать с диска, как у нашего клиента, у которого поиск залетал и он стал прыгать от счастья. Вывод: Пишите to_tsquery() в запросе вместо использования from to_tsquery q.

Read more... )

Profile

obartunov: (Default)
obartunov

November 2012

S M T W T F S
    1 23
456789 10
11121314151617
18192021222324
252627282930 

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags