Thread: Количество атрибутов в таблице
Здравствуйте.
В описании ограничений постгреса сказано, что таблица может содержать 2500-1600 столбцов в зависимости от типа этих самых столбцов.
Каким образом эта зависимость проявляется?
Например, если я имею столбцы int4, varchar, bytea. В основном int4 и varchar, то сколько столбцов может быть?
Сергей Карин
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
---559023410-2026989069-1113915931=:4405
Content-Type: TEXT/PLAIN; charset=koi8-r; format=flowed
Content-Transfer-Encoding: 8BIT
On Tue, 19 Apr 2005, Sergey Karin wrote:
> Здравствуйте.
>
>
>
> В описании ограничений постгреса сказано, что таблица может содержать
> 2500-1600 столбцов в зависимости от типа этих самых столбцов.
>
> Каким образом эта зависимость проявляется?
>
> Например, если я имею столбцы int4, varchar, bytea. В основном int4 и
> varchar, то сколько столбцов может быть?
размер страницы ограничивает, запись (tuple) должна помещаться.
250 - это если у тебя все колонки toastable и тогда требуется 32 байта,
а 1600 - если у тебя по 4 байта как в int4.
>
>
>
> Сергей Карин
>
>
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
---559023410-2026989069-1113915931=:4405--
Пояснения уже дали, но прошу обратить внимание, что там же где пишется про это ограничение говорится и что такое количество колонок в таблице - не очень хорошая идея и часто свидетельствует о неправильном дизайне БД. Помоему ещё где-то было упоминание, что при околопредельном количестве колонок в таблице, производительность СУБД на таких таблицах будет хуже. Так что нужно серьёзно подумать - надо ли оно? > Здравствуйте. > > > > В описании ограничений постгреса сказано, что таблица может содержать > 2500-1600 столбцов в зависимости от типа этих самых столбцов. > > Каким образом эта зависимость проявляется? > > Например, если я имею столбцы int4, varchar, bytea. В основном int4 и > varchar, то сколько столбцов может быть? > > > > Сергей Карин > -- С уважением, Виктор
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
---559023410-2022861571-1113969207=:28522
Content-Type: TEXT/PLAIN; charset=koi8-r; format=flowed
Content-Transfer-Encoding: 8BIT
On Wed, 20 Apr 2005, Viktor Vislobokov wrote:
> Пояснения уже дали, но прошу обратить внимание, что там же где пишется про
> это ограничение говорится и что такое количество колонок в таблице - не очень
> хорошая идея и часто свидетельствует о неправильном дизайне БД. Помоему ещё
> где-то было упоминание, что при околопредельном количестве колонок в таблице,
> производительность СУБД на таких таблицах будет хуже. Так что нужно серьёзно
> подумать - надо ли оно?
Иногда требуется, но обычно поиск идет только по нескольким атрибутам,
а остальные нужны только для показа. Поэтому, мы запихиваем эти все остальные
атрибуты в хэш и храним в одном поле. Есть даже спец. тип данных
hstore (www.sai.msu.su/~megera/postgres/gist) для этого,
а если не хочется с этим связываться и работа идет с perl, то можно
хранить стринговое представление хэша (Data::Dumper).
>
>> Здравствуйте.
>>
>>
>> В описании ограничений постгреса сказано, что таблица может содержать
>> 2500-1600 столбцов в зависимости от типа этих самых столбцов.
>>
>> Каким образом эта зависимость проявляется?
>>
>> Например, если я имею столбцы int4, varchar, bytea. В основном int4 и
>> varchar, то сколько столбцов может быть?
>>
>>
>> Сергей Карин
>>
>
>
>
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
---559023410-2022861571-1113969207=:28522--
-----Original Message----- From: pgsql-ru-general-owner@postgresql.org [mailto:pgsql-ru-general-owner@postgresql.org] On Behalf Of Oleg Bartunov Sent: Wednesday, April 20, 2005 7:53 AM To: vvislobokov@lukoilperm.ru Cc: 'pgsql-ru-general' Subject: [OBORONA-SPAM] Re: [pgsql-ru-general] Количество On Wed, 20 Apr 2005, Viktor Vislobokov wrote: > Пояснения уже дали, но прошу обратить внимание, что там же где пишется про > это ограничение говорится и что такое количество колонок в таблице - не очень > хорошая идея и часто свидетельствует о неправильном дизайне БД. Помоему ещё > где-то было упоминание, что при околопредельном количестве колонок в таблице, > производительность СУБД на таких таблицах будет хуже. Так что нужно серьёзно > подумать - надо ли оно? Иногда требуется, но обычно поиск идет только по нескольким атрибутам, а остальные нужны только для показа. Поэтому, мы запихиваем эти все остальные атрибуты в хэш и храним в одном поле. Есть даже спец. тип данных hstore (www.sai.msu.su/~megera/postgres/gist) для этого, а если не хочется с этим связываться и работа идет с perl, то можно хранить стринговое представление хэша (Data::Dumper). Я полностью согласен с тем, что очень большое количество атрибутов в таблице говорит о неправильном дизайне. Однако у меня данный вопрос возник вот почему. Я занимаюсь разработкой ГИС с использованием связки postgres + postgis. Вот. А там устройство такое. Слой - это отдельная таблица. Строками таблицы являются объекты. Каждый объект кроме географии имеет некоторое количество атрибутов. Для всех объектов слоя их количество фиксировано, но может быть очень большим. Понятно, что в 99.99999% случаев количество атрибутов не перевалит даже за 50, но если ограничение есть, то надо об этом знать заранее. А теперь к вопросу о том, почему не получается хранить все атрибуты в хэше. Все сторонние системы, например OGR (http://www.gdal.org/ogr), считают, что атрибут объекта - это отдельное поле таблицы. Исходя из этого они и работают... Вот такие вот дела. > >> Здравствуйте. >> >> >> В описании ограничений постгреса сказано, что таблица может содержать >> 2500-1600 столбцов в зависимости от типа этих самых столбцов. >> >> Каким образом эта зависимость проявляется? >> >> Например, если я имею столбцы int4, varchar, bytea. В основном int4 и >> varchar, то сколько столбцов может быть? >> >> >> Сергей Карин >> > > > Regards, Oleg _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1691952160-1113987067=:28522 Content-Type: TEXT/PLAIN; charset=koi8-r; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 20 Apr 2005, Sergey Karin wrote: > > > -----Original Message----- > From: pgsql-ru-general-owner@postgresql.org > [mailto:pgsql-ru-general-owner@postgresql.org] On Behalf Of Oleg Bartunov > Sent: Wednesday, April 20, 2005 7:53 AM > To: vvislobokov@lukoilperm.ru > Cc: 'pgsql-ru-general' > Subject: [OBORONA-SPAM] Re: [pgsql-ru-general] Количество > > On Wed, 20 Apr 2005, Viktor Vislobokov wrote: > >> Пояснения уже дали, но прошу обратить внимание, что там же где пишется про >> это ограничение говорится и что такое количество колонок в таблице - не > очень >> хорошая идея и часто свидетельствует о неправильном дизайне БД. Помоему > ещё >> где-то было упоминание, что при околопредельном количестве колонок в > таблице, >> производительность СУБД на таких таблицах будет хуже. Так что нужно > серьёзно >> подумать - надо ли оно? > > Иногда требуется, но обычно поиск идет только по нескольким атрибутам, > а остальные нужны только для показа. Поэтому, мы запихиваем эти все > остальные > атрибуты в хэш и храним в одном поле. Есть даже спец. тип данных > hstore (www.sai.msu.su/~megera/postgres/gist) для этого, > а если не хочется с этим связываться и работа идет с perl, то можно > хранить стринговое представление хэша (Data::Dumper). > > > Я полностью согласен с тем, что очень большое количество атрибутов в таблице > говорит о неправильном дизайне. Однако у меня данный вопрос возник вот > почему. Я занимаюсь разработкой ГИС с использованием связки postgres + > postgis. Вот. А там устройство такое. Слой - это отдельная таблица. Строками > таблицы являются объекты. Каждый объект кроме географии имеет некоторое > количество атрибутов. Для всех объектов слоя их количество фиксировано, но > может быть очень большим. Понятно, что в 99.99999% случаев количество > атрибутов не перевалит даже за 50, но если ограничение есть, то надо об этом > знать заранее. > А теперь к вопросу о том, почему не получается хранить все атрибуты в хэше. > Все сторонние системы, например OGR (http://www.gdal.org/ogr), считают, что > атрибут объекта - это отдельное поле таблицы. Исходя из этого они и > работают... Это не аргумент, а просто требование отдельно взятого продукта. Кто мешает написать небольшой слой, который выдает атрибут по требованию из того-же хэша ? > Вот такие вот дела. > >> >>> Здравствуйте. >>> >>> >>> В описании ограничений постгреса сказано, что таблица может содержать >>> 2500-1600 столбцов в зависимости от типа этих самых столбцов. >>> >>> Каким образом эта зависимость проявляется? >>> >>> Например, если я имею столбцы int4, varchar, bytea. В основном int4 и >>> varchar, то сколько столбцов может быть? >>> >>> >>> Сергей Карин >>> >> >> >> > > Regards, > Oleg > _____________________________________________________________ > Oleg Bartunov, sci.researcher, hostmaster of AstroNet, > Sternberg Astronomical Institute, Moscow University (Russia) > Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ > phone: +007(095)939-16-83, +007(095)939-23-83 > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > Regards, Oleg _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---559023410-1691952160-1113987067=:28522--
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-570397931-1113987494=:28522 Content-Type: TEXT/PLAIN; charset=koi8-r; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 20 Apr 2005, Sergey Karin wrote: > > говорит о неправильном дизайне. Однако у меня данный вопрос возник вот > почему. Я занимаюсь разработкой ГИС с использованием связки postgres + > postgis. Вот. А там устройство такое. Слой - это отдельная таблица. Строками Кстати, о ГИС. Я по профессии астроном и мы работаем с очень похожими данными. Это каталоги звезд с координатами на сфере. Может тебе будет интересно узнать как еще можно работать с такими данными без PostGIS http://www.sai.msu.su/~megera/oddmuse/index.cgi/SkyPixelization Там пока не много написано, нет описания как делать join двух каталогов, но промежуточные результаты вполне обещающи - join 20mln звезд с 500mln занимает около 50минут на средней машинке, которая еще и стоит в продакшн. Это означает, что стандартные гисовские задачи с несколькими тысячами точек можно решать просто в online. Правда, это все точки. Regards, Oleg _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---559023410-570397931-1113987494=:28522--