Re: Re: [pgsql-ru-general] Re: [pgsql-ru-general] hstore & plperl & массивы
| От | Dmitry E. Oboukhov | 
|---|---|
| Тема | Re: Re: [pgsql-ru-general] Re: [pgsql-ru-general] hstore & plperl & массивы | 
| Дата | |
| Msg-id | 20110311091249.GA26491@apache.rbscorp.ru обсуждение исходный текст  | 
		
| Ответ на | Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: [pgsql-ru-general] hstore & plperl & массивы (Dmitriy Igrishin <dmitigr@gmail.com>) | 
| Список | pgsql-ru-general | 
DI> Какой смысл использовать массив, когда можно просто DI> добавлять данные в таблицу в хронологическом порядке? DI> Причём хронологию будет фиксировать сама СУБД (очень просто DI> достижимо использованием now() в качестве значения по умолчанию). ну смысл простой: 1. данные преимущественно выбираются только скопом (очень редко из скопа делается срез, но тут можно сделать unnest), на уровне тех скопов которыми они выбираются они и группируются в массивы. то есть по сути массив измерений - одна сущность :) 2. выбор таблица на 500 тыс строк vs таблица на 5-50 млн строк, при том что индексы нафиг там не нужны (включая PRIMARY KEY) пихает прямо в направлении использования массива в столбике :). а когда там станет 5 млн строк, то распакованная таблица будет 50-500 млн. 5 млн это еще тот размер который в случае чего быстро (относительно) восстанавливается после сбоев (я правда со сбоями на постгрисе не работал, а на mysql мы от этого порога начинали таблицы дробить на более мелкие) -- . ''`. 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
Вложения
В списке pgsql-ru-general по дате отправления: