Thread: Re: [pgsql-ru-general] Массивы: REFERENCES и выборки
А 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-----
>
> А 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
Attachment
Ну почитайте, возможно наведёт на мысли 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----- >
> Ну почитайте, возможно наведёт на мысли > http://postgresql.ru.net/manual/ddl-partitioning.html ну да примерно так мы и партицируем. вот пример точки: Схема | Имя | Тип | Владелец | Размер | Описание --------+-------------------+--------------------+----------+------------+-------------- public | points | таблица | points | 8192 bytes | Точки от GPS public | points_2011_10_12 | таблица | points | 16 kB | public | points_2011_10_13 | таблица | points | 240 kB | public | points_2011_10_14 | таблица | points | 144 kB | public | points_2011_10_15 | таблица | points | 80 kB | public | points_2011_10_16 | таблица | points | 104 kB | public | points_2011_10_17 | таблица | points | 80 kB | public | points_2011_10_18 | таблица | points | 80 kB | public | points_2011_10_19 | таблица | points | 184 kB | public | points_2011_10_20 | таблица | points | 1944 kB | public | points_2011_10_21 | таблица | points | 3256 kB | ... public | points_2012_12_10 | таблица | points | 115 MB | public | points_2012_12_11 | таблица | points | 151 MB | public | points_2012_12_12 | таблица | points | 164 MB | public | points_2012_12_13 | таблица | points | 164 MB | public | points_2012_12_14 | таблица | points | 177 MB | public | points_2012_12_15 | таблица | points | 176 MB | public | points_2012_12_16 | таблица | points | 93 MB | все таблички пишутся по дню, имеют собственные индексы итп итд обращение к общей points позволяет вообще все точки вытащить за весь период их сбора. вопрос тут в том что бывает что чисто исторически уже написано много кода который делает INSERT в родительскую таблицу, тогда мы партицируем методом переноса данных из основной в архивную WITH "del" AS (DELETE ... RETURNING) INSERT INTO "archive_2012_21_21" SELECT "del"; кроме VACUUM вроде никаких различий между методами :) > FOREIGN не догма, надо разбираться для чего оно нужно, тем более что > функциональность FOREIGN KEY долгое время поддерживалась в PostgreSQL > с помощью триггеров, значит и вам никто не мешает написать триггеры, > работающие с разбиениями так, как это нужно вам. Главное, что > разбиения позволяют существенно оптимизировать скорость выполнения > запросов. триггеры вещь довольно неудобная в плане того что просто в консольке сразу не видно что на что ограничивается и куда относится. а так да триггеры можно юзать -- . ''`. 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