pg.ddx.io pgsql-ru-general@postgresql.org mailing list archive
help / color / mirror / Atom feed=?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDT19HawdTYINTBwsw=?= =?KOI8-R?B?ycPZINDPIM7BycLPzNjbxc3VINPP19DBxMXOycAg09TSz8vJ?=
31+ messages / 13 participants
[nested] [flat]
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDT19HawdTYINTBwsw=?= =?KOI8-R?B?ycPZINDPIM7BycLPzNjbxc3VINPP19DBxMXOycAg09TSz8vJ?=
@ 2006-05-30 16:27 Anton Maksimenkov <anton200@gmail.com>
0 siblings, 0 replies; 31+ messages in thread
From: Anton Maksimenkov @ 2006-05-30 16:27 UTC (permalink / raw)
To: Alexander M. Pravking <fduch@antar.bryansk.ru>; +Cc: pgsql-ru-general
> SELECT dir, price
> FROM voip_tariffs
> WHERE trid = <группа тарифов>
> AND dir <= <вызываемый номер>
> AND <вызываемый номер> ~ ('^' || dir)
> ORDER BY trid DESC, dir DESC
> LIMIT 1;
> Возможно, не самый оптимальный вариант, однако меня вполне устраивает:
ОГРОМНОЕ спасибо, этот вариант гораздо быстрее!!!
billing=# explain analyze SELECT *, (SELECT code FROM a_voip_codes
WHERE code <= v.called_station_id AND v.called_station_id ~('^' ||
code) order by code desc limit 1) AS code
FROM a_voip AS v WHERE user_name = 'dixi' and tm between '2006-04-10'
and '2006-04-20';
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Bitmap Heap Scan on a_voip v (cost=553.06..3410.96 rows=257
width=166) (actual time=35.572..54.364 rows=371 loops=1)
Recheck Cond: (((user_name)::text = 'dixi'::text) AND (tm >=
'2006-04-10 00:00:00'::timestamp without time zone) AND (tm <=
'2006-04-20 00:00:00'::timestamp without time zone))
-> BitmapAnd (cost=553.06..553.06 rows=257 width=0) (actual
time=34.989..34.989 rows=0 loops=1)
-> Bitmap Index Scan on a_voip_user_name (cost=0.00..23.67
rows=1905 width=0) (actual time=2.278..2.278 rows=1894 loops=1)
Index Cond: ((user_name)::text = 'dixi'::text)
-> Bitmap Index Scan on a_voip_tm (cost=0.00..529.15
rows=41191 width=0) (actual time=31.572..31.572 rows=41280 loops=1)
Index Cond: ((tm >= '2006-04-10 00:00:00'::timestamp
without time zone) AND (tm <= '2006-04-20 00:00:00'::timestamp without
time zone))
SubPlan
-> Limit (cost=0.00..9.30 rows=1 width=8) (actual
time=0.034..0.035 rows=1 loops=371)
-> Index Scan Backward using a_voip_codes_pkey on
a_voip_codes (cost=0.00..27.91 rows=3 width=8) (actual
time=0.028..0.028 rows=1 loops=371)
Index Cond: ((code)::text <= ($0)::text)
Filter: (($0)::text ~ ('^'::text || (code)::text))
Total runtime: 55.841 ms
(13 rows)
То есть почти в 16 раз быстрее, чем LIKE.
> К тому же, при этом не требуется построение индекса с
> varchar_pattern_ops.
А это что такое, поясни?
> Я вообще рекомендовал бы такие вычисления делать не при выборке
> статистики, а при складывании в базу, скажем, из BEFORE INSERT триггера.
Да, я тоже сообразил, что можно поле а-ля matched_code завести, в
которое триггером вставлять значения. Однако имеется ситуация когда
таблица кодов изменяется
Поэтому сообразил триггер для INSERT/UPDATE/DELETE таблицы кодов.
Понятно зачем - может появиться более длинный код ( то есть скажем так
более детально описывающий "куда звоним"), таким образом ранее
совпавшие более короткие коды, которые совпадают с начальными цифрами
нового длинного кода, нужно "перепроверить" на предмет совпадения с
новым более длинным кодом.
А вообще, теперь даже обновление ВСЕЙ таблицы звонков (она пока
небольшая, порядка 300 000 строк) происходит довольно быстро :
billing=# explain analyze UPDATE a_voip SET matched_code = (SELECT
code FROM a_voip_codes WHERE code <= a_voip.called_station_id AND
a_voip.called_station_id ~('^' || code) order by code desc limit 1);
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Seq Scan on a_voip (cost=0.00..2953677.82 rows=316130 width=168)
(actual time=0.335..58485.877 rows=305364 loops=1)
SubPlan
-> Limit (cost=0.00..9.30 rows=1 width=8) (actual
time=0.168..0.170 rows=1 loops=305364)
-> Index Scan Backward using a_voip_codes_pkey on
a_voip_codes (cost=0.00..27.91 rows=3 width=8) (actual
time=0.161..0.161 rows=1 loops=305364)
Index Cond: ((code)::text <= ($0)::text)
Filter: (($0)::text ~ ('^'::text || (code)::text))
Total runtime: 170037.350 ms
(7 rows)
Выполнения варианта с LIKE я не долждался, отменил, итак понятно, что
регексп здесь рулит.
> И, кстати, нынешняя реализация регулярных выражений гораздо быстрее
> LIKE, так что тоже советую попробовать поиграться.
--
engineer
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDw0s/CzA==?= =?KOI8-R?B?xc3BIN7V19PU18nUxczYzs/T1Mkg0sXHydPU0sE=?=
@ 2007-09-07 14:14 Sergey Konoplev <gray.ru@gmail.com>
0 siblings, 1 reply; 31+ messages in thread
From: Sergey Konoplev @ 2007-09-07 14:14 UTC (permalink / raw)
To: Teodor Sigaev <teodor@sigaev.ru>; +Cc: pgsql-ru-general
Вот
test=# show lc_ctype; show server_encoding;
lc_ctype
-------------
ru_RU.UTF-8
(1 row)
server_encoding
-----------------
UTF8
(1 row)
2007/9/7, Teodor Sigaev <teodor@sigaev.ru>:
> Покажи вывод show lc_ctype; show server_encoding; плз
>
> > pgdb:~ # locale |grep LC_CTYPE
> > LC_CTYPE=ru_RU.UTF-8
> Это ни на что не влияет - локаль базы задается при initdb
>
> > test=# show client_encoding;
> > client_encoding
> > -----------------
> > UTF8
> > (1 row)
>
> Это локаль клиента, а не сервера
>
> --
> Teodor Sigaev E-mail: teodor@sigaev.ru
> WWW: http://www.sigaev.ru/
>
--
Regards,
Sergey Konoplev
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDw0s/CzA==?= =?KOI8-R?B?xc3BIN7V19PU18nUxczYzs/T1Mkg0sXHydPU0sE=?=
@ 2007-09-07 19:13 Sergey Konoplev <gray.ru@gmail.com>
parent: Sergey Konoplev <gray.ru@gmail.com>
0 siblings, 1 reply; 31+ messages in thread
From: Sergey Konoplev @ 2007-09-07 19:13 UTC (permalink / raw)
To: Teodor Sigaev <teodor@sigaev.ru>; +Cc: pgsql-ru-general
test=# select lower('ЙЦУКЕН'); show lc_collate;
lower
--------
йцукен
(1 row)
lc_collate
-------------
ru_RU.UTF-8
(1 row)
SUSE LINUX Enterprise Server 9
2007/9/7, Teodor Sigaev <teodor@sigaev.ru>:
> Интересно. select lower('ЙЦУКЕН'); show lc_collate;? OS?
>
>
> Sergey Konoplev wrote:
> > Вот
> >
> > test=# show lc_ctype; show server_encoding;
> > lc_ctype
> > -------------
> > ru_RU.UTF-8
> > (1 row)
> >
> > server_encoding
> > -----------------
> > UTF8
> > (1 row)
> >
> >
> >
> > 2007/9/7, Teodor Sigaev <teodor@sigaev.ru>:
> >> Покажи вывод show lc_ctype; show server_encoding; плз
> >>
> >>> pgdb:~ # locale |grep LC_CTYPE
> >>> LC_CTYPE=ru_RU.UTF-8
> >> Это ни на что не влияет - локаль базы задается при initdb
> >>
> >>> test=# show client_encoding;
> >>> client_encoding
> >>> -----------------
> >>> UTF8
> >>> (1 row)
> >> Это локаль клиента, а не сервера
> >>
> >> --
> >> Teodor Sigaev E-mail: teodor@sigaev.ru
> >> WWW: http://www.sigaev.ru/
> >>
> >
> >
>
> --
> Teodor Sigaev E-mail: teodor@sigaev.ru
> WWW: http://www.sigaev.ru/
>
--
Regards,
Sergey Konoplev
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDw0s/CzA==?= =?KOI8-R?B?xc3BIN7V19PU18nUxczYzs/T1Mkg0sXHydPU0sE=?=
@ 2007-09-11 18:03 Sergey Konoplev <gray.ru@gmail.com>
parent: Sergey Konoplev <gray.ru@gmail.com>
0 siblings, 0 replies; 31+ messages in thread
From: Sergey Konoplev @ 2007-09-11 18:03 UTC (permalink / raw)
To: Teodor Sigaev <teodor@sigaev.ru>; +Cc: pgsql-ru-general
Привет сообщество. Не хочу показаться навязчивым, но очень хотелось бы
знать, стоит ли в моём случае возлагать надежды на регулярные
выражения?
07.09.07, Sergey Konoplev<gray.ru@gmail.com> написал(а):
> test=# select lower('ЙЦУКЕН'); show lc_collate;
> lower
> --------
> йцукен
> (1 row)
>
> lc_collate
>
> -------------
> ru_RU.UTF-8
> (1 row)
>
>
> SUSE LINUX Enterprise Server 9
>
> 2007/9/7, Teodor Sigaev <teodor@sigaev.ru>:
> > Интересно. select lower('ЙЦУКЕН'); show lc_collate;? OS?
> >
> >
> > Sergey Konoplev wrote:
> > > Вот
> > >
> > > test=# show lc_ctype; show server_encoding;
> > > lc_ctype
> > > -------------
> > > ru_RU.UTF-8
> > > (1 row)
> > >
> > > server_encoding
> > > -----------------
> > > UTF8
> > > (1 row)
> > >
> > >
> > >
> > > 2007/9/7, Teodor Sigaev <teodor@sigaev.ru>:
> > >> Покажи вывод show lc_ctype; show server_encoding; плз
> > >>
> > >>> pgdb:~ # locale |grep LC_CTYPE
> > >>> LC_CTYPE=ru_RU.UTF-8
> > >> Это ни на что не влияет - локаль базы задается при initdb
> > >>
> > >>> test=# show client_encoding;
> > >>> client_encoding
> > >>> -----------------
> > >>> UTF8
> > >>> (1 row)
> > >> Это локаль клиента, а не сервера
> > >>
> > >> --
> > >> Teodor Sigaev E-mail: teodor@sigaev.ru
> > >> WWW: http://www.sigaev.ru/
> > >>
> > >
> > >
> >
> > --
> > Teodor Sigaev E-mail: teodor@sigaev.ru
> > WWW: http://www.sigaev.ru/
> >
>
>
> --
> Regards,
> Sergey Konoplev
>
--
Regards,
Sergey Konoplev
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDEwdTBLdfSxc0=?= =?KOI8-R?B?0SDXIMLB2sUgz9TMyd7BwNTT0SDP1CDTydPUxc3O2cg=?=
@ 2007-10-12 21:04 Nikolay Samokhvalov <samokhvalov@gmail.com>
0 siblings, 0 replies; 31+ messages in thread
From: Nikolay Samokhvalov @ 2007-10-12 21:04 UTC (permalink / raw)
To: Alexander Kuprijanov <sanya-spb@list.ru>; +Cc: pgsql-ru-general
On 10/12/07, Alexander Kuprijanov <sanya-spb@list.ru> wrote:
> Добрый день
>
> такая вот проблемка:
> ========================
> $ date; echo 'select CURRENT_TIME;' | psql MyBase
> Fri Oct 12 14:51:10 MSD 2007
> timetz
> --------------------
> 10:51:11.031388+00
> (1 row)
> ========================
>
>
> подскажите где подправить?
>
> Как я понимаю что-то связано с часовыми поясами... но почему-то сбилось
>
> Если еще и ткнете в мануал, буду благодарен.
Не вижу проблемки :-)
Постгрес "сидит" в нулевом часовом поясе.
http://www.postgresql.org/docs/8.2/interactive/datatype-datetime.html#DATATYPE-TIMEZONES
На выбор:
- set timezone to 'Europe/Moscow'; на лету каждый раз
- подправить в postgresql.conf
- alter database XYZ set timezone to 'Europe/Moscow'; (или то же для
user) /* надо помнить, что pg_dump такие свойства не сдампит, только
pg_dumpall */
--
Best regards,
Nikolay
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDw0sk=?= =?KOI8-R?B?18XExc7JxSDz9eLkINcg08/P1NfF1NPU18k=?= =?KOI8-R?B?xSDTz9fSxc3Fzs7ZzSDLz83N1c7Jy8HDyc8=?= =?KOI8-R?B?zs7ZzSDU0sXCz9fBzsnRzSAtIFNRTDoyMDA5?=
@ 2008-12-21 19:49 Yuriy Rusinov <yrusinov@gmail.com>
0 siblings, 0 replies; 31+ messages in thread
From: Yuriy Rusinov @ 2008-12-21 19:49 UTC (permalink / raw)
To: Dmitry Turin <dmitry.turin@belarusbank.minsk.by>; +Cc: pgsql-ru-general
Hi, Dmitry !
>>> Т.е. ваша позиция:
>>> 1) рендерить должна не СУБД, а программист вручную, вызывая функциии OpenGL или DirectX
>>> 2) пространственные данные должны храниться в двух БД: в реляционной и в OpenGL (DirectX)
>>> Хотелось бы услышать аргументы в защиту этих двух пунктов.
Вот аргументы
1. Отрисовка делается на некотором виджете с заданными размерами,
палитрой, разрешением, etc, известными клиенту, а сервер о них знать
не может и не должен.
2. OpenGL -- это не база данных, это метод отрисовки чего-л.
> Разные платформы - это X11 vs. Microsoft Window System.
> СУБД должна отправлять данные в формате платформы-получателя,
> т.е. если клиент под Иксами, то в формате иксов,
> если клиент под виндой, в формате винды.
СУБД получается должна узнавать, какая платформа у пользователя,
размеры виджета отрисовки, масштабирование, палитру.
>> , например один рисует средствами OpenGL, другой
>> DirectX, третий cairo, ...,
>
> Эти библиотеки остаются незадействованными.
>
> 1) пользователь не рисует объект - объект хранится в БД
> 2) значения полей заменяются в SELECT-e
>
>> И ещё вопрос, для каких задач это все делалось
Вопрос остался не отвеченным.
>
> "Все ранее известные 3D-интерфейсы (3DMLW, 3DXML, COLLADA / OpenGL, DirectX) разработаны
> с расчетом на некие когнитивные способности, которыми, как показывают эксперименты,
> средний человек на самом деле не обладает.
Что за эксперименты и какие способности ?
>> , проверялось
>
> Укажите процедуру проверки, я скажу, выполнялась она или нет.
Сравнить производительность при отрисовке средствами БД и OpenGL.
--
Best regards,
Sincerely yours,
Yuriy Rusinov.
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSD10NLB18zFzsnFIMLB2sE=?= =?KOI8-R?B?zckgz9Qgyc3FzskgzMDCz8fPINDPzNjaz9fB1MXM0Q==?=
@ 2009-05-12 14:11 dewil <dewil.ru@gmail.com>
0 siblings, 0 replies; 31+ messages in thread
From: dewil @ 2009-05-12 14:11 UTC (permalink / raw)
To: ; +Cc: pgsql-ru-general
>
> Welcome to psql 8.0.15, the PostgreSQL interactive terminal.
>
> Установка postgres выполнялась из дерева портежей gentoo.
По моему у вас очень старые порты. Сейчас актуальная ветка 8.3, а у вас 8.0
Запрос пароля в консоли лечится в файле pg_hba.conf
К примеру сделать такую замену:
local all all trust
на
local all all password
--
dwl-ripe
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDtzs/Hz9DSz8PF08/Szg==?= =?KOI8-R?B?z9PU2CDQz9PUx9LF08E=?=
@ 2009-07-27 17:40 Ilia Kantor <iliakan@gmail.com>
0 siblings, 0 replies; 31+ messages in thread
From: Ilia Kantor @ 2009-07-27 17:40 UTC (permalink / raw)
To: pgsql-ru-general
Постгрес не умеет параллелить запросы.
Многопроцессорность достигается исключительно за счет множества процессов БД.
То есть, разные клиенты будут использовать разные процессы и, как
следствие, разные процессоры.
27 июля 2009 г. 14:20 пользователь apm (korjavin@gmail.com) написал:
> Возможно ли что б запрос типа
> select sum () .... where ip << '10.1.1.1/24' group by .... having ...
>
> выполнялся на нескольких процессорах сразу?
>
> Или один запрос всегда один процессор?
>
> И также интересно, запросы от 4 клиентов разбегутся по 4 процесоорам?
>
>
> --
> Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-ru-general
>
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDF3cUg0sHaINDSzyDSxcfV?= =?KOI8-R?B?zNHSztnFINfZ0sHWxc7J0SDEzNEgdXRmOA==?=
@ 2009-12-01 15:33 Vyacheslav Kalinin <vka@mgcp.com>
0 siblings, 0 replies; 31+ messages in thread
From: Vyacheslav Kalinin @ 2009-12-01 15:33 UTC (permalink / raw)
To: Mihail Nasedkin <m.nasedkin@gmail.com>; +Cc: pgsql-ru-general
Там не все гладко:
http://archives.postgresql.org/pgsql-general/2008-04/msg01315.php
2009/12/1 Mihail Nasedkin <m.nasedkin@gmail.com>
> Доброго всем.
>
> Продолжение по теме
> http://archives.postgresql.org/pgsql-ru-general/2007-09/msg00006.php
> Там автор вроде так и не разобрался. Я тоже столкнулся. Стал копать -
> ничего не выходит.
>
> Т.е. не все гадко с регулярными выражениями c UTF8:
>
>
> test=# select 'Вася' ~ E'\\w';
> ?column?
> ----------
> f
> (1 запись)
>
> test=# select 'Vasya' ~ E'\\w';
> ?column?
> ----------
> t
> (1 запись)
>
> Перепрверил все encodings, locale - все стоит в ru_RU.UTF-8
>
> Может кто продвинулся в понимании этой проблемы?
>
>
> --
> ---
> С уважением,
> Михаил Наседкин
>
> --
> Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-ru-general
>
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDvws7P18zFzsnFINPF0tc=?= =?KOI8-R?B?xdLB?=
@ 2010-03-25 10:08 Sergey Konoplev <gray.ru@gmail.com>
1 sibling, 0 replies; 31+ messages in thread
From: Sergey Konoplev @ 2010-03-25 10:08 UTC (permalink / raw)
To: Mihail Nasedkin <m.nasedkin@gmail.com>; +Cc: pgsql-ru-general
2010/3/25 Mihail Nasedkin <m.nasedkin@gmail.com>:
> Раньше вроде не делал, работало поверх.
>
> Может все же лучше убрать прежнюю установку?
Не могу ничего конкретного привести против установки поверх, но я бы
убрал прежнюю хотя бы из чисто эстетических соображений.
>
> Спасибо.
> --
> ---
> С уважением,
> Михаил Наседкин
>
> --
> Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-ru-general
>
--
Sergey Konoplev
Blog: http://gray-hemp.blogspot.com /
Linkedin: http://ru.linkedin.com/in/grayhemp /
JID/GTalk: gray.ru@gmail.com / Skype: gray-hemp / ICQ: 29353802
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDvws7P18zFzsnFINPF0tc=?= =?KOI8-R?B?xdLB?=
@ 2010-03-25 10:19 Sergey Konoplev <gray.ru@gmail.com>
1 sibling, 1 reply; 31+ messages in thread
From: Sergey Konoplev @ 2010-03-25 10:19 UTC (permalink / raw)
To: Sergej Kandyla <sk.paix@gmail.com>; +Cc: Mihail Nasedkin <m.nasedkin@gmail.com>; pgsql-ru-general
2010/3/25 Sergej Kandyla <sk.paix@gmail.com>:
> Использовать пакеты (rpm, dpkg) религия не позволяет?
Постарайтесь в следующий раз выражать мысли без негатива, это отталкивает людей.
> сорсинсталинг не есть try way. (Imho)
Это верно.
>
>> Бакап баз понятно.
>>
>> А нужно ли из старой директории компиляциии из исходников делать:
>> # make uninstall
>>
>> предже, чем в новых исходниках сделать
>> # make install
>> ?
>>
>> Раньше вроде не делал, работало поверх.
>>
>> Может все же лучше убрать прежнюю установку?
>>
>> Спасибо.
>>
>
>
> --
> Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-ru-general
>
--
Sergey Konoplev
Blog: http://gray-hemp.blogspot.com /
Linkedin: http://ru.linkedin.com/in/grayhemp /
JID/GTalk: gray.ru@gmail.com / Skype: gray-hemp / ICQ: 29353802
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDywdPT2czLwSArIFBvc3RncmVz?=
@ 2010-03-26 12:56 Sergey Konoplev <gray.ru@gmail.com>
parent: Sergey Konoplev <gray.ru@gmail.com>
0 siblings, 0 replies; 31+ messages in thread
From: Sergey Konoplev @ 2010-03-26 12:56 UTC (permalink / raw)
To: polaxn@gmail.com; +Cc: pgsql-ru-general
2010/3/26 <polaxn@gmail.com>:
> Здравствуйте, Postgres.
>
> Вопрос: не ужели у русской части админов Postgres на столько
> редко возникают вопросы и проблемы?
> рассылка проходит настолько редко, что все ее слушатели с
> большой охотой вставляют свои пять копеек!!
>
> Это может говорить о двух вещах:
> 1. Postgres дествилельно надежен и продуман.
> 2. не могу придумать. :-)
>
>
> Ваше мнение?
А давайте не будем?
>
>
> --
> С уважением,
> Polaxn mailto:polaxn@gmail.com
>
>
> --
> Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-ru-general
>
--
Sergey Konoplev
Blog: http://gray-hemp.blogspot.com /
Linkedin: http://ru.linkedin.com/in/grayhemp /
JID/GTalk: gray.ru@gmail.com / Skype: gray-hemp / ICQ: 29353802
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDrINfP0NLP09UgzyDQ1cLM?= =?KOI8-R?B?ycvBw8nRyCDQ0s8gUG9zdGdyZVNRTA==?=
@ 2010-06-03 10:30 Ivan Zolotukhin <ivan.zolotukhin@gmail.com>
1 sibling, 1 reply; 31+ messages in thread
From: Ivan Zolotukhin @ 2010-06-03 10:30 UTC (permalink / raw)
To: Evgeny M. Baldin <E.M.Baldin@inp.nsk.su>; +Cc: pgsql-ru-general@postgresql.org, Oleg Bartunov <oleg@sai.msu.su>
Добрый день,
PostgreSQL не может не использоваться в науке по понятным причинам.
Вот список индексируемых в ADS физико-астрономических публикаций, в
которых явно упомянут PostgreSQL:
http://adsabs.harvard.edu/cgi-bin/nph-abs_connect?db_key=AST&db_key=PRE&qform=AST&arxiv_...
Это все в основном proceedings, а не рецензируемые статьи, но такова
тенденция -- технические публикации с описанием инфраструктуры плохо
принимают в научные журналы.
3 основные (по цитированиям, пусть их и немного) публикации из этого списка:
- Storing and Accessing the Largest Astronomical Catalogs with the
SAI CAS Project, http://adsabs.harvard.edu/abs/2007ASPC..376...34K
- Comprehensive Metadata Query Interface for Heterogeneous Data
Archives Based on Open-Source PostgreSQL ORDBMS,
http://adsabs.harvard.edu/abs/2007ASPC..376..355Z
- Q3C, Quad Tree Cube -- The new Sky-indexing Concept for Huge
Astronomical Catalogues and its Realization for Main Astronomical
Queries (Cone Search and Xmatch) in Open Source Database PostgreSQL,
http://adsabs.harvard.edu/abs/2006ASPC..351..735K
Наверняка Олег Бартунов сможет накидать сюда еще ссылок из других
отраслей науки.
--
Best regards,
Ivan
2010/6/3 Evgeny M. Baldin <E.M.Baldin@inp.nsk.su>:
> Добрый день
>
> Возможно, кому-нибудь будет полезно, а то я в своё время почти ничего не
> нашёл на тему использования PostgreSQL в науке (одна статья).
>
> Предыстория: традиционно у нас в институте в диссертации кроме физической
> основы должны быть методическая часть. Обычно это часть связанная с железом
> (кусок детектора или ускорителя). В своей работе я в качестве методической
> части описал БД эксперимента которую я в своё время организовал.
>
> Защита прошла и слово PostgreSQL я во время неё упомянул.
>
> То есть при необходимости теперь можно сослаться на мою диссертацию когда
> где-то нужно будет подтверждение об использовании PostgreSQL в науке.
>
> Анонсы диссертаций: http://www.inp.nsk.su/news/defences.ru.shtml - смотреть
> на позицию "Балдин Евгений Михайлович"
>
> Там же есть ссылка на электронную версию моей диссертации:
> http://www.inp.nsk.su/news/defences/Baldin_E_M_disser.pdf
>
> С уважением
> Евгений
> --
> Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-ru-general
>
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDrINfP0NLP09UgzyDQ1cLM?= =?KOI8-R?B?ycvBw8nRyCDQ0s8gUG9zdGdyZVNRTA==?=
@ 2010-06-03 12:14 Oleg Bartunov <oleg@sai.msu.su>
parent: Ivan Zolotukhin <ivan.zolotukhin@gmail.com>
0 siblings, 0 replies; 31+ messages in thread
From: Oleg Bartunov @ 2010-06-03 12:14 UTC (permalink / raw)
To: Ivan Zolotukhin <ivan.zolotukhin@gmail.com>; +Cc: Evgeny M. Baldin <E.M.Baldin@inp.nsk.su>; pgsql-ru-general
Ой, постгрес настолько много используется, что я не вижу причину поднимать
дискуссию. Нам много пишут как раз из научных проектов.
Другое дело, что в наших диссертациях пока не принято писать
об используемых технологиях.
Олег
On Thu, 3 Jun 2010, Ivan Zolotukhin wrote:
> Добрый день,
>
> PostgreSQL не может не использоваться в науке по понятным причинам.
> Вот список индексируемых в ADS физико-астрономических публикаций, в
> которых явно упомянут PostgreSQL:
>
> http://adsabs.harvard.edu/cgi-bin/nph-abs_connect?db_key=AST&db_key=PRE&qform=AST&arxiv_...
>
> Это все в основном proceedings, а не рецензируемые статьи, но такова
> тенденция -- технические публикации с описанием инфраструктуры плохо
> принимают в научные журналы.
>
> 3 основные (по цитированиям, пусть их и немного) публикации из этого списка:
>
> - Storing and Accessing the Largest Astronomical Catalogs with the
> SAI CAS Project, http://adsabs.harvard.edu/abs/2007ASPC..376...34K
> - Comprehensive Metadata Query Interface for Heterogeneous Data
> Archives Based on Open-Source PostgreSQL ORDBMS,
> http://adsabs.harvard.edu/abs/2007ASPC..376..355Z
> - Q3C, Quad Tree Cube -- The new Sky-indexing Concept for Huge
> Astronomical Catalogues and its Realization for Main Astronomical
> Queries (Cone Search and Xmatch) in Open Source Database PostgreSQL,
> http://adsabs.harvard.edu/abs/2006ASPC..351..735K
>
> Наверняка Олег Бартунов сможет накидать сюда еще ссылок из других
> отраслей науки.
>
> --
> Best regards,
> Ivan
>
>
> 2010/6/3 Evgeny M. Baldin <E.M.Baldin@inp.nsk.su>:
>> Добрый день
>>
>> Возможно, кому-нибудь будет полезно, а то я в своё время почти ничего не
>> нашёл на тему использования PostgreSQL в науке (одна статья).
>>
>> Предыстория: традиционно у нас в институте в диссертации кроме физической
>> основы должны быть методическая часть. Обычно это часть связанная с железом
>> (кусок детектора или ускорителя). В своей работе я в качестве методической
>> части описал БД эксперимента которую я в своё время организовал.
>>
>> Защита прошла и слово PostgreSQL я во время неё упомянул.
>>
>> То есть при необходимости теперь можно сослаться на мою диссертацию когда
>> где-то нужно будет подтверждение об использовании PostgreSQL в науке.
>>
>> Анонсы диссертаций: http://www.inp.nsk.su/news/defences.ru.shtml - смотреть
>> на позицию "Балдин Евгений Михайлович"
>>
>> Там же есть ссылка на электронную версию моей диссертации:
>> http://www.inp.nsk.su/news/defences/Baldin_E_M_disser.pdf
>>
>> С уважением
>> Евгений
>> --
>> Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-ru-general
>>
>
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDrINfP0NLP09UgzyDQ1cLM?= =?KOI8-R?B?ycvBw8nRyCDQ0s8gUG9zdGdyZVNRTA==?=
@ 2010-06-03 14:34 Serguei Mokhov <serguei@gmail.com>
1 sibling, 0 replies; 31+ messages in thread
From: Serguei Mokhov @ 2010-06-03 14:34 UTC (permalink / raw)
To: Evgeny M. Baldin <E.M.Baldin@inp.nsk.su>; +Cc: pgsql-ru-general
Ещё пара мастерских диссертаций здесь если надо:
- Li, Qiu Wen
"Reengineering an object-oriented framework for extensible query optimization"
http://clues.concordia.ca/record=b2186428~S0
2004
- Wang, Guang
"Linking CORAL to MySQL and PostgreSQL"
http://clues.concordia.ca/record=b2156737~S0
2004
- Wang, Ju
"Implementing the postgreSQL query optimizer within the OPT++ framework"
http://clues.concordia.ca/record=b2110586~S0
2002
- Shen, Xin
"An architecture tradeoff analysis of postgreSQL"
http://clues.concordia.ca/record=b2066657~S0
2002
Я так думаю может стоит составить глобальный список литературы по постгресу
и вывесить его где-нибудь -- чтобы когда подобные вопросы возникают можно
просто ссылочкой ответить.
-s
2010/6/3 Evgeny M. Baldin <E.M.Baldin@inp.nsk.su>:
> Добрый день
>
> Возможно, кому-нибудь будет полезно, а то я в своё время почти ничего не
> нашёл на тему использования PostgreSQL в науке (одна статья).
>
> Предыстория: традиционно у нас в институте в диссертации кроме физической
> основы должны быть методическая часть. Обычно это часть связанная с железом
> (кусок детектора или ускорителя). В своей работе я в качестве методической
> части описал БД эксперимента которую я в своё время организовал.
>
> Защита прошла и слово PostgreSQL я во время неё упомянул.
>
> То есть при необходимости теперь можно сослаться на мою диссертацию когда
> где-то нужно будет подтверждение об использовании PostgreSQL в науке.
>
> Анонсы диссертаций: http://www.inp.nsk.su/news/defences.ru.shtml - смотреть
> на позицию "Балдин Евгений Михайлович"
>
> Там же есть ссылка на электронную версию моей диссертации:
> http://www.inp.nsk.su/news/defences/Baldin_E_M_disser.pdf
>
> С уважением
> Евгений
> --
> Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-ru-general
--
Serguei Mokhov
http://www.cs.concordia.ca/~mokhov
http://marf.sf.net | http://sf.net/projects/marf
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDh08nOyNLPzs7B0SDN1cw=?= =?KOI8-R?B?2NTJLc3B09TF0iDSxdDMycvBw8nRLiD3z9rNz9bO2cU=?= =?KOI8-R?B?INDSz8LMxc3ZIMkg0sXbxc7J0Q==?=
@ 2010-10-18 07:44 =?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?= <corochoone@gmail.com>
1 sibling, 0 replies; 31+ messages in thread
From: Виктор Вислобоков @ 2010-10-18 07:44 UTC (permalink / raw)
To: pgsql-ru-general
Насколько я понял, в 9.0 та репликация, которая объявлена как Hot Standby -
это не мультимастерная репликация. Она завязана на WAL мастер-сервера и
позволят получить на удалённом сервере точную копию БД путём онлайнового
наката WAL логов. При этом база данных на удалённом сервере доступна только
для запросов на чтение со всеми вытекающими.
Т.е. для случаев, когда такая репликация не подходит, по прежнему актуальны
старые решения репликации со всеми их проблемами.
17 октября 2010 г. 17:13 пользователь <simplevolk@gmail.com> написал:
> Здравствуйте!
> У меня вопрос- как в новой версии PostgreSQL обстоит с мультимастер
> репликацией?
> Я порыл в инете этот вопрос накопал,что в общем случае проблема не
> решена,решена только в частных.
>
> Накопал также и то,что там есть 3 возможных конфликта репликации-
>
> 1. Ошибка обновления
> 2. Конфликт уникальности.
> 3. Конфликт удаления.
>
> Скажите, эти проблемы до сих пор актуальны?Решены ли они в новой версии?
>
>
> Спасибо.
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDh08nOyNLPzs7B0SDN1cw=?= =?KOI8-R?B?2NTJLc3B09TF0iDSxdDMycvBw8nRLiD3z9rNz9bO2cU=?= =?KOI8-R?B?INDSz8LMxc3ZIMkg0sXbxc7J0Q==?=
@ 2010-10-18 11:33 =?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?= <corochoone@gmail.com>
1 sibling, 0 replies; 31+ messages in thread
From: Виктор Вислобоков @ 2010-10-18 11:33 UTC (permalink / raw)
To: pgsql-ru-general
Зачем? Ну например, если вы хотите разнести обслуживание клиентов по разным
датацентрам, даже если объём записи при этом не очень-то велик. Или если вы
хотите балансировать нагрузку с одновременным получением отказоустойчивости
в случае умирания одного сервера.
18 октября 2010 г. 11:55 пользователь Sergej Kandyla <sk.paix@gmail.com>написал:
> simplevolk@gmail.com wrote:
>
>> Здравствуйте!
>> У меня вопрос- как в новой версии PostgreSQL обстоит с мультимастер
>> репликацией?
>>
>
> Простите, а зачем?
>
> Имхо - это зло, и поиск приключений на свою жопу.
> При интенсивных записях избыточные расходы на синхронизацию
> мастер-мастер слишком существенны,
> причем растут экспоненциально в зависимости от колличества серверов в
> группе репликации.
>
>
>
> Я порыл в инете этот вопрос накопал,что в общем случае проблема не
>> решена,решена только в частных.
>>
>> Накопал также и то,что там есть 3 возможных конфликта репликации-
>>
>> 1. Ошибка обновления
>> 2. Конфликт уникальности.
>> 3. Конфликт удаления.
>>
>> Скажите, эти проблемы до сих пор актуальны?Решены ли они в новой версии?
>>
>
> Никакие продвинутые механизмы разрешения репликационных конфликтов не
> могут гарантировать 100% консистентность данных,
> посему не лучше ли избрать по возможности более простую архитектуру?
>
>
>
>>
>> Спасибо.
>>
>
>
> --
> Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-ru-general
>
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDzz9rEwc7JxSBHSVNUIMnOxA==?= =?KOI8-R?B?xcvTwc0gxMzRINPSwdfOxc7J0SDLwdLUyc7PyyAoaW50YXI=?= =?KOI8-R?B?cmF5KQ==?=
@ 2011-02-06 14:29 Sergey Konoplev <gray.ru@gmail.com>
0 siblings, 0 replies; 31+ messages in thread
From: Sergey Konoplev @ 2011-02-06 14:29 UTC (permalink / raw)
To: Oleg Bartunov <oleg@sai.msu.su>; +Cc: leopard_ne@inbox.ru <leopard_ne@inbox.ru>; pgsql-ru-general
Привет всем,
2011/2/6 Oleg Bartunov <oleg@sai.msu.su>:
> Можно попробовать использовать GIN индекс по полю diff_array, который
> ускоряет операцию &&
А может быть имеет смысл использовать tsearch, построив gin/gist
индекс по to_tsvector(array_to_string(diff_array, ' ')) и используя
ts_rank() в ORDR BY?
Тогда запрос будет выглядеть как-то так:
SELECT ..., ts_rank(to_tsvector(array_to_string(diff_array, ' ')),
query) AS rank
FROM some_table, to_tsquery('1 2 3 4 5') AS query
WHERE to_tsvector(array_to_string(diff_array, ' ')) @@ query
ORDER BY rank
LIMIT 10;
А фильтровать >60% уже на клиенте обрабатывая всего 10 результатов.
Не будет ли это быстрее работать?
>
> CREATE OR REPLACE FUNCTION intersection(anyarray, anyarray) RETURNS anyarray
> as $$
> SELECT ARRAY(
> SELECT $1[i]
> FROM generate_series( array_lower($1, 1), array_upper($1, 1) ) WHERE
> ARRAY[$1[i]] && $2 ); $$ language sql;
>
>
> Олег
>
> On Sun, 6 Feb 2011, leopard_ne@inbox.ru wrote:
>
>> Добрый день. Прошу совета у сообщества.
>> Есть простой метод сравнения картинок -
>>
>> http://leopard.in.ua/2010/12/09/bystroe-sravnenie-izobrazhenij-s-pomoshhyu-rubyphp-i-postgresql/
>>
>> В таблицу записывается в поле типа integer[] масив с числами (пусть поле
>> будет "diff_array" в таблице "some_table"). Далее происходит такой метод
>> поиска похожих картинок (пусть есть массив картинки "{1,3,4,5,...}"
>> размером 225, как в статье)
>>
>> Select some_table.*, round((icount(some_table.diff_array::int[] &
>> '{1,3,4,5,...}'::int[])::numeric / (225)::numeric) * 100, 2) as
>> simillar_percentes FROM some_table WHERE
>> round((icount(some_table.diff_array::int[] &
>> '{1,3,4,5,...}'::int[])::numeric / (225)::numeric) * 100, 2) >= 60 AND
>> id != img_id ORDER BY round((icount(some_table.diff_array::int[] &
>> '{1,3,4,5,...}'::int[])::numeric / (225)::numeric) * 100, 2) DESC LIMIT 10
>>
>> Проблемный кусок, который используется 3 раза тут в запросе:
>>
>> round((icount(some_table.diff_array::int[] &
>> '{1,3,4,5,...}'::int[])::numeric / (225)::numeric) * 100, 2)
>>
>> Хотелось бы как то по такому условию создать индекс, поскольку скорость
>> падает (индекс gist__intbig_ops добавлял, скорость все равно не
>> увеличивается).
>> Для простоты вычисления размера массива (чтобы не задать 225 = 15*15
>> матрица), можно сделать так функцию:
>>
>> round((icount(some_table.diff_array::int[] &
>> '{1,3,4,5,...}'::int[])::numeric /
>> ((icount(some_table.diff_array::int[]) + icount('{1,3,4,5,...}'::int[]))
>> / 2)::numeric) * 100, 2)
>>
>> Документацию
>> http://www.sai.msu.su/~megera/postgres/talks/gist_tutorial.html
>> <http://www.sai.msu.su/%7Emegera/postgres/talks/gist_tutorial.html; я
>> прочитал, но не работаю на C, и поэтому, возникло еще больше вопросов,
>> как все таки мне можно создать индекс на подобное условие. Буду
>> благодарен за любые советы или помощь.
>>
>>
>
> Regards,
> Oleg
> _____________________________________________________________
> Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
> Sternberg Astronomical Institute, Moscow University, Russia
> Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
> phone: +007(495)939-16-83, +007(495)939-23-83
> --
> Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-ru-general
>
--
Sergey Konoplev
Blog: http://gray-hemp.blogspot.com /
Linkedin: http://ru.linkedin.com/in/grayhemp /
JID/GTalk: gray.ru@gmail.com / Skype: gray-hemp
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDBzsHMz8cgbXlzcWwnzs/HzyBT?= =?KOI8-R?B?UUxfQ0FMQ19GT1VORF9ST1dT?=
@ 2011-03-20 12:08 Sergi Vladykin <sergi.vladykin@gmail.com>
0 siblings, 0 replies; 31+ messages in thread
From: Sergi Vladykin @ 2011-03-20 12:08 UTC (permalink / raw)
To: Dmitry E. Oboukhov <unera@debian.org>; +Cc: pgsql-ru-general
Можно использовать windowing функцию count(*) over(). Подробнее см.
http://www.postgresql.org/docs/current/static/tutorial-window.html
regards,
S.Vladykin
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDw0sHXyczYztnKIGJhY2t1cC4g?= =?KOI8-R?B?68HLPw==?=
@ 2011-07-01 13:37 Sergey Konoplev <gray.ru@gmail.com>
0 siblings, 0 replies; 31+ messages in thread
From: Sergey Konoplev @ 2011-07-01 13:37 UTC (permalink / raw)
To: Peter Teslenko <smartchecker@gmail.com>; +Cc: pgsql-ru-general
См. pg_dumpall -g
2011/7/1 Peter Teslenko <smartchecker@gmail.com>:
> Приветствую.
>
> Как максимально корректно перетащить базу с одного сервера на другой?
> Если делать pg_dumpall, то туда летят все базы, все мне нужны.
> Есть делать pg_dump конкретной базы, то нет сохранятся информация о
> пользователе.
> Как правильно?
>
> --
> Peter Teslenko
> Jabber: peter@jabber.mcicb.ru
>
> --
> Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-ru-general
>
--
Sergey Konoplev
Blog: http://gray-hemp.blogspot.com /
Linkedin: http://ru.linkedin.com/in/grayhemp /
JID/GTalk: gray.ru@gmail.com / Skype: gray-hemp
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDi3MvB0CDiwdrZIOTBzs4=?= =?KOI8-R?B?2cg=?=
@ 2011-07-15 08:13 Sergey Konoplev <gray.ru@gmail.com>
0 siblings, 0 replies; 31+ messages in thread
From: Sergey Konoplev @ 2011-07-15 08:13 UTC (permalink / raw)
To: Galin, Aleksey <algalin@mera.ru>; +Cc: pgsql-ru-general
Привет,
2011/7/14 Galin, Aleksey <algalin@mera.ru>:
> Можно ли сделать так чтобы данные фильтровались или по типу (Type: FOREIGN
> DATA WRAPPER) или по пустому значению схемы (Schema: -)
По типу без хаков не получится. Флаг -N исключит указанную схему из
бэкапа. Подробнее тут
http://www.postgresql.org/docs/current/interactive/app-pgdump.html
>
>
>
> __________
>
> Best regards,
>
> Alexey
>
>
>
>
--
Sergey Konoplev
Blog: http://gray-hemp.blogspot.com /
Linkedin: http://ru.linkedin.com/in/grayhemp /
JID/GTalk: gray.ru@gmail.com / Skype: gray-hemp
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDrz9PRy8kg0yDP1M3Fzs8=?= =?KOI8-R?B?yiDMxdTOxcfPINfSxc3Fzsk=?=
@ 2011-10-05 09:32 Timon <timosha@gmail.com>
0 siblings, 0 replies; 31+ messages in thread
From: Timon @ 2011-10-05 09:32 UTC (permalink / raw)
To: pgsql-ru-general
5 октября 2011 г. 13:37 пользователь Alexander M. Pravkin
<fduch@antar.bryansk.ru> написал:
> On Mon, 2011-10-03 at 13:18 +0300, Alexey Klyukin wrote:
>> > Обновил сегодня системную zoneinfo (FreeBSD 8.2), привязал к ней же
>> > postgresql (в 8.4.8 ещё не внесли tzdata 2011i).
>>
>> На момент вопроса решения я не знал, но в списке изменений 8.4.9 есть упоминание про апдейт информации о часовых поясах, думаю что проблема уже решена.
>
> Уверен, что нет. tzdata-2011k в плане русских TZ ничем не изменилась, а
> в release notes от 4.8.9
в релизнотах как раз написано про обновление временных зон
"Update time zone data files to tzdata release 2011i for DST law
changes in Canada, Egypt, Russia, Samoa, and South Sudan."
+ согласно коммиту
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=67efa666a5b29ecd19e0f3191a1433fbd5...
отличается, и эти изменения в 8.4.9 присутсвуют
--
All bugs reserved
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDBx8fSxcfB1M/SINDPIME=?= =?KOI8-R?B?x8fSxcfB1M/Swc0=?=
@ 2012-04-13 13:42 Sergey Konoplev <gray.ru@gmail.com>
0 siblings, 0 replies; 31+ messages in thread
From: Sergey Konoplev @ 2012-04-13 13:42 UTC (permalink / raw)
To: Dmitry E. Oboukhov <unera@debian.org>; +Cc: pgsql-ru-general
Привет,
On Fri, Apr 13, 2012 at 1:05 PM, Dmitry E. Oboukhov <unera@debian.org> wrote:
> WITH "a" AS (select * FROM (VALUES (ARRAY[1,2,3,3,4]), (ARRAY[1,2,2,3,4])) t )
> SELECT array_agg(unnest(column1)) FROM "a";
>
> ERROR: set-valued function called in context that cannot accept a set
>
>
> А хотели бы получить общий массив {1,2,3,3,4,1,2,2,3,4}
>
> Как это можно сделать?
WITH a AS (select * FROM (VALUES (ARRAY[1,2,3,3,4]), (ARRAY[1,2,2,3,4])) t )
SELECT array_agg(c) FROM (SELECT unnest(column1) AS c FROM a) AS sq;
>
> И второй вопрос:
>
> допустим имеется массив:
>
> {1,2,3,3,4,1,2,2,3,4}
>
> Как можно посчитать число уникальных элементов в нем?
>
> SELECT COUNT(DISTINCT unnest(ARRAY[1,2,3,3,4,1,2,2,3,4]))
>
> дает ту же ошибку
> --
>
> . ''`. Dmitry E. Oboukhov
> : :' : email: unera@debian.org jabber://UNera@uvw.ru
> `. `~' GPGKey: 1024D / F8E26537 2006-11-21
> `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
--
Sergey Konoplev
Blog: http://gray-hemp.blogspot.com
LinkedIn: http://ru.linkedin.com/in/grayhemp
JID/GTalk: gray.ru@gmail.com Skype: gray-hemp
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDv09TB1MvJINTP18HSwS4=?=
@ 2012-04-25 06:23 =?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?= <corochoone@gmail.com>
0 siblings, 0 replies; 31+ messages in thread
From: Виктор Вислобоков @ 2012-04-25 06:23 UTC (permalink / raw)
To: vlads <vlads@ngs.ru>; +Cc: pgsql-ru-general
Вариантов несколько.
Многое зависит от количества товаров. Если каталог небольшой можно
использовать триггеры, если в нём сотни тысяч или миллионы позиций, а
также частое обновление, триггеры могут оказаться нерациональными. В
этом случае, возможно лучшим решением будет периодический запуск
процедуры, которая будет обсчитывать и сохранять остатки.
Можно и вообще без триггеров обойтись и всю логику с подсчётами
остатков выполнять прямо в вмомент внесения изменений в количество
товара. Т.е. запрашивать по другим таблицам остаток, менять его и
сохранять. Всё зависит от размера каталога.
Чтобы не было проблем с несколькими пользователями - используйте
транзакции, для этого они собственно и предназначены.
25 апреля 2012 г. 4:59 пользователь vlads <vlads@ngs.ru> написал:
> Допустим, есть справочник товаров (tovar) с двумя полями
> x(Serial) и name(text)
> т.е. код товара и его наименование.
> А также справочник складов (sklad) с аналогичными полями:
> x(Serial) и name(text)
> Третий справочник: справочник операций прихода/расхода (oper):
> x(Serial), dat(data), xtovar(int), xsklad(int) и kol(int)
> где поле kol - это кол-во прихода или расхода (штук) товара
> dat - дата операции.
> а xtovar и xsklad - ссылки на коды товара и склада.
> Задача такова. При добавлении строки oper система должна автоматически в
> каком-нибудь третьем справочнике хранить актуальные остатки товара:
> справочник остатков (ost)
> x(Serial), xtovar(int), xsklad(int) и kol(int).
>
> Проблема, с которой я к Вам обращаюсь: Как я понимаю - это работа с
> триггерами. Алгоритм такой:
> - Триггер должен сначала понять, есть ли вообще строка в справочнике ost
> (xtovar-xsklad) и если её нету - создать новую с нулевой суммой.
> - Ну и в существующую или в созданную новую строку добавить/отнять
> необходимую сумму товара.
>
> Вопросов несколько:
> 1) Если это делают несколько пользователей - не случится ли так что два
> пользователя одновременно не найдут пару (xtovar-xsklad) и создадут каждый
> свою такую пару. И получится дубляж строк. Как этого избежать.
> 2) Как понять триггеру, что нужной строки с уникальной парой (xtovar-xsklad)
> нет, чтобы он создал.
> 3) Может кто то какой то другой вариант решения проблемы.
>
> Заранее спасибо.
>
> --
> Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-ru-general
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDtwdPTydfZOiBSRUZFUkVOQ0VTIMk=?= =?KOI8-R?B?INfZws/Sy8k=?=
@ 2012-12-15 00:05 Sergey Konoplev <gray.ru@gmail.com>
1 sibling, 0 replies; 31+ messages in thread
From: Sergey Konoplev @ 2012-12-15 00:05 UTC (permalink / raw)
To: Dmitry E. Oboukhov <unera@debian.org>; +Cc: pgsql-ru-general
2012/12/14 Dmitry E. Oboukhov <unera@debian.org>:
> было три таблички
>
> orders
> drivers
>
> и
>
> orders_drivers - oid, did, dist, time
>
> за годы работы получается что orders_drivers скопилась огромная.
>
> ну и хочется ее свернуть в массивы композитных полей вида
> (did,dist,time)[] и класть эти массивчики в orders.
>
> фича в том что с ордером работа кратковременная, далее он в базе
> просто лежит.
>
> а вот джоин на водителей через промежуточную стомилионную таблицу
> orders_drivers уже тяжел.
Какой именно запрос тормозит, можно посмотреть на него, на explain
analyze и на индексы?
> но вот что хочется:
>
> 1. таки иметь FOREIGN (ну или если это невозможно то хотя бы CHECK, на
> проверку валидности did'ов (наличия их в drivers)
FK/CHECK не получится, триггерами делайте проверку.
> 2. иметь возможность выбрать только одно подзначение массива в массив,
> то есть записи
>
> 1, ..., {(23,222,0.5),(22,332,0.6)}
> 2, ..., {(11,222,27)}
>
> преобразовать выборкой в
>
> 1, ..., {23,22}
> 2, ..., {11}
>
> поодиночке понятно как это сделать. а внутри выборки есть возможность?
SELECT ..., array(SELECT did FROM unnest(drivers_orders_array)) FROM orders ...
> ну и последнее.
> иногда хочется выбрать orders по входящему набору did
>
> как такой столбик проиндексировать лучше?
Сделать отдельное поле drivers_orders_did_array и на него gin индекс.
Чтобы индекс работал см.
http://www.postgresql.org/docs/9.2/interactive/intarray.html.
> ну и похожая про индексы задача:
>
> таблица
>
> тема, сообщение, {метка1,метка2,метка3}
>
> метки хранятся прямо в текстовом виде (когда-то хранили опять же в
> отдельной таблице, потом из за нагрузки денормализовали)
> метки текстовые
>
>
> хочется отвечать на вопрос
>
> WHERE tags @> {метка1,метка2}
>
> как массивы лучше проиндексировать?
Опять же http://www.postgresql.org/docs/9.2/interactive/intarray.html.
>
> сейчас построили 5 разных индексов по 5 первым меткам...
>
> говорят что
> такое можно GIST/GIN индексом индексировать, но у меня что-то не
> получается правильно такой индекс построить по текстовому массиву.
> можно пример как этими гист/гин пользоваться?
> операции какие-то они хотят, где они описаны?
>
> --
>
> . ''`. Dmitry E. Oboukhov
> : :' : email: unera@debian.org jabber://UNera@uvw.ru
> `. `~' GPGKey: 1024D / F8E26537 2006-11-21
> `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEAREDAAYFAlDLuJkACgkQq4wAz/jiZTd2xACg5DAnSoq44ydR2WtLgMvOF6tA
> bJYAoJG9JH0WGooQP4NiAC5HlNUm+jm4
> =EroA
> -----END PGP SIGNATURE-----
>
--
Sergey Konoplev
Database and Software Architect
http://www.linkedin.com/in/grayhemp
Phones:
USA +1 415 867 9984
Russia, Moscow +7 901 903 0499
Russia, Krasnodar +7 988 888 1979
Skype: gray-hemp
Jabber: gray.ru@gmail.com
--
Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ru-general
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDtwdPTydfZOiBSRUZFUkVOQ0VTIMk=?= =?KOI8-R?B?INfZws/Sy8k=?=
@ 2012-12-16 11:32 =?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?= <corochoone@gmail.com>
1 sibling, 1 reply; 31+ messages in thread
From: Виктор Вислобоков @ 2012-12-16 11:32 UTC (permalink / raw)
To: Dmitry E. Oboukhov <unera@debian.org>; +Cc: pgsql-ru-general
А PARTITION не вариант?
Типа рекомендованный (по документации) способ разбираться с большими
таблицами в PostgreSQL как я понимаю.
15 декабря 2012 г., 3:39 пользователь Dmitry E. Oboukhov
<unera@debian.org> написал:
> было три таблички
>
> orders
> drivers
>
> и
>
> orders_drivers - oid, did, dist, time
>
> за годы работы получается что orders_drivers скопилась огромная.
>
> ну и хочется ее свернуть в массивы композитных полей вида
> (did,dist,time)[] и класть эти массивчики в orders.
>
> фича в том что с ордером работа кратковременная, далее он в базе
> просто лежит.
>
> а вот джоин на водителей через промежуточную стомилионную таблицу
> orders_drivers уже тяжел.
>
>
> но вот что хочется:
>
> 1. таки иметь FOREIGN (ну или если это невозможно то хотя бы CHECK, на
> проверку валидности did'ов (наличия их в drivers)
> 2. иметь возможность выбрать только одно подзначение массива в массив,
> то есть записи
>
> 1, ..., {(23,222,0.5),(22,332,0.6)}
> 2, ..., {(11,222,27)}
>
> преобразовать выборкой в
>
> 1, ..., {23,22}
> 2, ..., {11}
>
> поодиночке понятно как это сделать. а внутри выборки есть возможность?
>
>
> ну и последнее.
> иногда хочется выбрать orders по входящему набору did
>
> как такой столбик проиндексировать лучше?
>
> ну и похожая про индексы задача:
>
> таблица
>
> тема, сообщение, {метка1,метка2,метка3}
>
> метки хранятся прямо в текстовом виде (когда-то хранили опять же в
> отдельной таблице, потом из за нагрузки денормализовали)
> метки текстовые
>
>
> хочется отвечать на вопрос
>
> WHERE tags @> {метка1,метка2}
>
> как массивы лучше проиндексировать?
>
> сейчас построили 5 разных индексов по 5 первым меткам...
>
> говорят что
> такое можно GIST/GIN индексом индексировать, но у меня что-то не
> получается правильно такой индекс построить по текстовому массиву.
> можно пример как этими гист/гин пользоваться?
> операции какие-то они хотят, где они описаны?
>
> --
>
> . ''`. Dmitry E. Oboukhov
> : :' : email: unera@debian.org jabber://UNera@uvw.ru
> `. `~' GPGKey: 1024D / F8E26537 2006-11-21
> `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEAREDAAYFAlDLuJkACgkQq4wAz/jiZTd2xACg5DAnSoq44ydR2WtLgMvOF6tA
> bJYAoJG9JH0WGooQP4NiAC5HlNUm+jm4
> =EroA
> -----END PGP SIGNATURE-----
>
--
Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ru-general
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDtwdPTydfZOiBSRUZFUkVOQ0VTIMk=?= =?KOI8-R?B?INfZws/Sy8k=?=
@ 2012-12-16 17:49 =?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?= <corochoone@gmail.com>
parent: =?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?= <corochoone@gmail.com>
0 siblings, 0 replies; 31+ messages in thread
From: Виктор Вислобоков @ 2012-12-16 17:49 UTC (permalink / raw)
To: Dmitry E. Oboukhov <unera@debian.org>; +Cc: pgsql-ru-general
Ну почитайте, возможно наведёт на мысли
http://postgresql.ru.net/manual/ddl-partitioning.html
FOREIGN не догма, надо разбираться для чего оно нужно, тем более что
функциональность FOREIGN KEY долгое время поддерживалась в PostgreSQL
с помощью триггеров, значит и вам никто не мешает написать триггеры,
работающие с разбиениями так, как это нужно вам. Главное, что
разбиения позволяют существенно оптимизировать скорость выполнения
запросов.
16 декабря 2012 г., 16:18 пользователь Dmitry E. Oboukhov
<unera@debian.org> написал:
>> А PARTITION не вариант?
>> Типа рекомендованный (по документации) способ разбираться с большими
>> таблицами в PostgreSQL как я понимаю.
>
> эмм.
>
> имеется таблица с FOREIGN от нее и FOREIGN на нее.
> как ее партицировать я не знаю.
>
> мы партишены применяем в двух вариантах:
>
> 1. данные пишутся изначально в какую-то партицию
> 2. данные всегда пишутся в одно место, но периодически кронскрипт
> выносит данные из этого места в партиции
>
> в обоих случаях непонятно что делать с FOREIGN
> --
>
> . ''`. Dmitry E. Oboukhov
> : :' : email: unera@debian.org jabber://UNera@uvw.ru
> `. `~' GPGKey: 1024D / F8E26537 2006-11-21
> `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEAREDAAYFAlDNvBAACgkQq4wAz/jiZTcHhACg4etzQ5dvYFHzy2rTStt7Ko5r
> UuwAoOwdNy8eOdTm5sABSGFcKB/y1zvc
> =Y04s
> -----END PGP SIGNATURE-----
>
--
Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ru-general
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDkxcTMz8vJIMkgRk9SRUlHTiAocGc=?= =?KOI8-R?B?OS4xLjIp?=
@ 2012-12-21 00:31 Sergey Konoplev <gray.ru@gmail.com>
0 siblings, 0 replies; 31+ messages in thread
From: Sergey Konoplev @ 2012-12-21 00:31 UTC (permalink / raw)
To: Dmitry E. Oboukhov <unera@debian.org>; +Cc: pgsql-ru-general
2012/12/20 Dmitry E. Oboukhov <unera@debian.org>:
> orders_logs - имеет FOREIGN на users и orders соответственно (uid,
> oid)
>
> Кронскрипт иногда юзерам обновляет статусы
>
> UPDATE
> users
> SET
> status = что-то там,
> time = NOW()
> WHERE
> id = что-то там
>
> а в orders_logs иногда пишутся события:
>
> INSERT INTO
> "orders_logs"
>
> ("uid", "oid", "time", "event")
> VALUES
> (123, 2345, NOW(), что-то там)
>
> и вот обновление статуса у юзера изредка встает в дедлок с инсертом в
> orders_logs.
>
> как такой дедлок можно вылечить?
Судя по всему инсерты идут пачками в транзакции, так?
Можно ли отказаться от транзакции, делая отдельные инсерты?
>
> --
>
> . ''`. Dmitry E. Oboukhov
> : :' : email: unera@debian.org jabber://UNera@uvw.ru
> `. `~' GPGKey: 1024D / F8E26537 2006-11-21
> `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEAREDAAYFAlDTkMoACgkQq4wAz/jiZTfTlACglZM7Kz5NeLjQzkC4EKMEW2By
> FPcAn3Iarn5vMK17ev2s9uCMvTSMSlVZ
> =YWp9
> -----END PGP SIGNATURE-----
>
--
Sergey Konoplev
Database and Software Architect
http://www.linkedin.com/in/grayhemp
Phones:
USA +1 415 867 9984
Russia, Moscow +7 901 903 0499
Russia, Krasnodar +7 988 888 1979
Skype: gray-hemp
Jabber: gray.ru@gmail.com
--
Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ru-general
^ permalink raw reply [nested|flat] 31+ messages in thread
* =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDOxSDJ09DPzNja1cXU09E=?= =?KOI8-R?B?IMnOxMXL0w==?=
@ 2012-12-28 23:53 Sergey Konoplev <gray.ru@gmail.com>
0 siblings, 0 replies; 31+ messages in thread
From: Sergey Konoplev @ 2012-12-28 23:53 UTC (permalink / raw)
To: Dmitry E. Oboukhov <unera@debian.org>; +Cc: pgsql-ru-general
On Fri, Dec 28, 2012 at 10:44 AM, Dmitry E. Oboukhov <unera@debian.org> wrote:
>> EXPLAIN ANALYZE select * FROM orders_drivers od JOIN drivers d ON d.id = od.did WHERE sid = 2;
> QUERY PLAN
> -----------------------------------------------------------------------------------------------------------------------------------------
> Hash Join (cost=808.82..144710.55 rows=486762 width=169) (actual time=0.276..2673.383 rows=667453 loops=1)
> Hash Cond: (od.did = d.id)
> -> Seq Scan on orders_drivers od (cost=0.00..100792.89 rows=11365887 width=30) (actual time=0.015..1149.398 rows=11333318 loops=1)
> -> Hash (cost=807.91..807.91 rows=260 width=139) (actual time=0.248..0.248 rows=260 loops=1)
> Buckets: 1024 Batches: 1 Memory Usage: 33kB
> -> Bitmap Heap Scan on drivers d (cost=93.12..807.91 rows=260 width=139) (actual time=0.057..0.189 rows=260 loops=1)
> Recheck Cond: (sid = 2)
> -> Bitmap Index Scan on drivers_sid_idx (cost=0.00..93.05 rows=260 width=0) (actual time=0.044..0.044 rows=301 loops=1)
> Index Cond: (sid = 2)
> Total runtime: 2704.437 ms
> (10 строк)
Можно посмотреть на explain analyze с enable_seqscan off?
>
> \d orders_drivers
>
> Колонка | Тип | Модификаторы
> ---------+--------------+-------------------------------------------------------------
> id | integer | NOT NULL DEFAULT nextval('orders_drivers_id_seq'::regclass)
> oid | integer |
> did | integer | NOT NULL
> dist | numeric(8,3) |
> time | integer |
> tid | integer | NOT NULL
> status | order_status | NOT NULL DEFAULT 'request'::order_status
> Индексы:
> "orders_drivers_pkey" PRIMARY KEY, btree (id)
> "orders_drivers_oid_did_ukey" UNIQUE, btree (oid, did)
> "orders_drivers_did_key" btree (did)
> "orders_drivers_status_idx" btree (status)
>
>
> \d drivers
>> \d drivers
> Таблица "public.drivers"
> Колонка | Тип | Модификаторы
> ---------------+-----------------------------+------------------------
> id | integer | NOT NULL
> ...
> sid | integer | NOT NULL
> ...
> Индексы:
> "drivers_pkey" PRIMARY KEY, btree (id)
> "drivers_auto_enabled_key" btree (auto_enabled) WHERE auto_enabled IS NOT NULL
> "drivers_auto_order_key" btree (auto_order)
> "drivers_is_bot_key" btree (is_bot) WHERE bot_latitude IS NOT NULL AND bot_longitude IS NOT NULL
> "drivers_lp_time_key" btree (lp_time) WHERE lp_time IS NOT NULL
> "drivers_removed_key" btree (removed)
> "drivers_sid_idx" btree (sid)
>
>
> почему по orders_drivers делается полный перебор?
>
> --
>
> . ''`. Dmitry E. Oboukhov
> : :' : email: unera@debian.org jabber://UNera@uvw.ru
> `. `~' GPGKey: 1024D / F8E26537 2006-11-21
> `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEAREDAAYFAlDd6HIACgkQq4wAz/jiZTcjygCeLfeiDLf4sXFtDQ6NNU5uja4F
> +0IAoIL8fvUt8N+umms6NVpY+g5dCP4Y
> =IbeT
> -----END PGP SIGNATURE-----
>
--
Sergey Konoplev
Database and Software Architect
http://www.linkedin.com/in/grayhemp
Phones:
USA +1 415 867 9984
Russia, Moscow +7 901 903 0499
Russia, Krasnodar +7 988 888 1979
Skype: gray-hemp
Jabber: gray.ru@gmail.com
--
Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ru-general
^ permalink raw reply [nested|flat] 31+ messages in thread
end of thread, other threads:[~2012-12-28 23:53 UTC | newest]
Thread overview: 31+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-05-30 16:27 =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDT19HawdTYINTBwsw=?= =?KOI8-R?B?ycPZINDPIM7BycLPzNjbxc3VINPP19DBxMXOycAg09TSz8vJ?= Anton Maksimenkov <anton200@gmail.com>
2007-09-07 14:14 =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDw0s/CzA==?= =?KOI8-R?B?xc3BIN7V19PU18nUxczYzs/T1Mkg0sXHydPU0sE=?= Sergey Konoplev <gray.ru@gmail.com>
2007-09-07 19:13 ` =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDw0s/CzA==?= =?KOI8-R?B?xc3BIN7V19PU18nUxczYzs/T1Mkg0sXHydPU0sE=?= Sergey Konoplev <gray.ru@gmail.com>
2007-09-11 18:03 ` =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDw0s/CzA==?= =?KOI8-R?B?xc3BIN7V19PU18nUxczYzs/T1Mkg0sXHydPU0sE=?= Sergey Konoplev <gray.ru@gmail.com>
2007-10-12 21:04 =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDEwdTBLdfSxc0=?= =?KOI8-R?B?0SDXIMLB2sUgz9TMyd7BwNTT0SDP1CDTydPUxc3O2cg=?= Nikolay Samokhvalov <samokhvalov@gmail.com>
2008-12-21 19:49 =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDw0sk=?= =?KOI8-R?B?18XExc7JxSDz9eLkINcg08/P1NfF1NPU18k=?= =?KOI8-R?B?xSDTz9fSxc3Fzs7ZzSDLz83N1c7Jy8HDyc8=?= =?KOI8-R?B?zs7ZzSDU0sXCz9fBzsnRzSAtIFNRTDoyMDA5?= Yuriy Rusinov <yrusinov@gmail.com>
2009-05-12 14:11 =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSD10NLB18zFzsnFIMLB2sE=?= =?KOI8-R?B?zckgz9Qgyc3FzskgzMDCz8fPINDPzNjaz9fB1MXM0Q==?= dewil <dewil.ru@gmail.com>
2009-07-27 17:40 =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDtzs/Hz9DSz8PF08/Szg==?= =?KOI8-R?B?z9PU2CDQz9PUx9LF08E=?= Ilia Kantor <iliakan@gmail.com>
2009-12-01 15:33 =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDF3cUg0sHaINDSzyDSxcfV?= =?KOI8-R?B?zNHSztnFINfZ0sHWxc7J0SDEzNEgdXRmOA==?= Vyacheslav Kalinin <vka@mgcp.com>
2010-03-25 10:08 ` =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDvws7P18zFzsnFINPF0tc=?= =?KOI8-R?B?xdLB?= Sergey Konoplev <gray.ru@gmail.com>
2010-03-25 10:19 ` =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDvws7P18zFzsnFINPF0tc=?= =?KOI8-R?B?xdLB?= Sergey Konoplev <gray.ru@gmail.com>
2010-03-26 12:56 ` =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDywdPT2czLwSArIFBvc3RncmVz?= Sergey Konoplev <gray.ru@gmail.com>
2010-06-03 10:30 ` =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDrINfP0NLP09UgzyDQ1cLM?= =?KOI8-R?B?ycvBw8nRyCDQ0s8gUG9zdGdyZVNRTA==?= Ivan Zolotukhin <ivan.zolotukhin@gmail.com>
2010-06-03 12:14 ` =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDrINfP0NLP09UgzyDQ1cLM?= =?KOI8-R?B?ycvBw8nRyCDQ0s8gUG9zdGdyZVNRTA==?= Oleg Bartunov <oleg@sai.msu.su>
2010-06-03 14:34 ` =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDrINfP0NLP09UgzyDQ1cLM?= =?KOI8-R?B?ycvBw8nRyCDQ0s8gUG9zdGdyZVNRTA==?= Serguei Mokhov <serguei@gmail.com>
2010-10-18 07:44 ` =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDh08nOyNLPzs7B0SDN1cw=?= =?KOI8-R?B?2NTJLc3B09TF0iDSxdDMycvBw8nRLiD3z9rNz9bO2cU=?= =?KOI8-R?B?INDSz8LMxc3ZIMkg0sXbxc7J0Q==?= =?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?= <corochoone@gmail.com>
2010-10-18 11:33 ` =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDh08nOyNLPzs7B0SDN1cw=?= =?KOI8-R?B?2NTJLc3B09TF0iDSxdDMycvBw8nRLiD3z9rNz9bO2cU=?= =?KOI8-R?B?INDSz8LMxc3ZIMkg0sXbxc7J0Q==?= =?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?= <corochoone@gmail.com>
2011-02-06 14:29 =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDzz9rEwc7JxSBHSVNUIMnOxA==?= =?KOI8-R?B?xcvTwc0gxMzRINPSwdfOxc7J0SDLwdLUyc7PyyAoaW50YXI=?= =?KOI8-R?B?cmF5KQ==?= Sergey Konoplev <gray.ru@gmail.com>
2011-03-20 12:08 =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDBzsHMz8cgbXlzcWwnzs/HzyBT?= =?KOI8-R?B?UUxfQ0FMQ19GT1VORF9ST1dT?= Sergi Vladykin <sergi.vladykin@gmail.com>
2011-07-01 13:37 =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDw0sHXyczYztnKIGJhY2t1cC4g?= =?KOI8-R?B?68HLPw==?= Sergey Konoplev <gray.ru@gmail.com>
2011-07-15 08:13 =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDi3MvB0CDiwdrZIOTBzs4=?= =?KOI8-R?B?2cg=?= Sergey Konoplev <gray.ru@gmail.com>
2011-10-05 09:32 =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDrz9PRy8kg0yDP1M3Fzs8=?= =?KOI8-R?B?yiDMxdTOxcfPINfSxc3Fzsk=?= Timon <timosha@gmail.com>
2012-04-13 13:42 =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDBx8fSxcfB1M/SINDPIME=?= =?KOI8-R?B?x8fSxcfB1M/Swc0=?= Sergey Konoplev <gray.ru@gmail.com>
2012-04-25 06:23 =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDv09TB1MvJINTP18HSwS4=?= =?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?= <corochoone@gmail.com>
2012-12-15 00:05 ` =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDtwdPTydfZOiBSRUZFUkVOQ0VTIMk=?= =?KOI8-R?B?INfZws/Sy8k=?= Sergey Konoplev <gray.ru@gmail.com>
2012-12-16 11:32 ` =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDtwdPTydfZOiBSRUZFUkVOQ0VTIMk=?= =?KOI8-R?B?INfZws/Sy8k=?= =?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?= <corochoone@gmail.com>
2012-12-16 17:49 ` =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDtwdPTydfZOiBSRUZFUkVOQ0VTIMk=?= =?KOI8-R?B?INfZws/Sy8k=?= =?KOI8-R?B?98nL1M/SIPfJ08zPws/Lz9c=?= <corochoone@gmail.com>
2012-12-21 00:31 =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDkxcTMz8vJIMkgRk9SRUlHTiAocGc=?= =?KOI8-R?B?OS4xLjIp?= Sergey Konoplev <gray.ru@gmail.com>
2012-12-28 23:53 =?KOI8-R?B?UmU6IFtwZ3NxbC1ydS1nZW5lcmFsXSDOxSDJ09DPzNja1cXU09E=?= =?KOI8-R?B?IMnOxMXL0w==?= Sergey Konoplev <gray.ru@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox