Re: Re: [pgsql-ru-general] Re: [pgsql-ru-general] hstore & plperl & массивы

From: "Dmitry E(dot) Oboukhov" <unera(at)debian(dot)org>
To: Dmitriy Igrishin <dmitigr(at)gmail(dot)com>
Cc: pgsql-ru-general(at)postgresql(dot)org
Subject: Re: Re: [pgsql-ru-general] Re: [pgsql-ru-general] hstore & plperl & массивы
Date: 2011-03-11 09:12:50
Message-ID: 20110311091249.GA26491@apache.rbscorp.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)debian(dot)org jabber://UNera(at)uvw(dot)ru
`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537

In response to

Responses

Browse pgsql-ru-general by date

  From Date Subject
Next Message Dmitriy Igrishin 2011-03-11 12:16:18 Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: [pgsql-ru-general] hstore & plperl & массивы
Previous Message Dmitriy Igrishin 2011-03-11 08:59:34 Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: [pgsql-ru-general] hstore & plperl & массивы