Re: Column as arrays.. more efficient than columns?

Поиск
Список
Период
Сортировка
От Ron Johnson
Тема Re: Column as arrays.. more efficient than columns?
Дата
Msg-id 46E13F10.3020000@cox.net
обсуждение исходный текст
Ответ на Re: Column as arrays.. more efficient than columns?  (Ow Mun Heng <Ow.Mun.Heng@wdc.com>)
Список pgsql-general
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/07/07 02:49, Ow Mun Heng wrote:
> On Fri, 2007-09-07 at 00:18 -0500, Ron Johnson wrote:
>> On 09/06/07 21:26, Ow Mun Heng wrote:
>> I've not arrived at any conclusion but merely
>>> exploring my options on which way would be the best to thread. I'm
>>> asking the list because I'm new in PG and after reading all those
>>> articles on highscalability etc.. majority of them are all using some
>>> kind of denormalised tables.
>> Correlation != causation.
>>
>> There *might* be a causal relationship between high scalability and
>> table denormalization, but I seriously doubt it.
>
> I can't refute you on this since I have no experience in this arena,
> only what I read in highscalbility.com (IIRC)
>
>>> Right now, there's 8 million rows of data in this one table, and growing
>>> at a rapid rate of ~2 million/week. I can significantly reduce this
>>> number down to 200K (i think by denormalising it) and shrink the table
>>> size.
>> Even presuming you only insert data SIX hours per day, that's only
>> 13.3 inserts per second.  Not very impressive.
>
> Data is inserted 24 hours a day, but not at the same rate each
> sec/minute. The problem isn't really the data-insertion, it's already
> inserted in a normalised manner. It's the selection of data. (OLTP
> datahouse) which takes a longer time and which is the area of worry.

Datahouse or "data warehouse"?

- --
Ron Johnson, Jr.
Jefferson LA  USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFG4T8QS9HxQb37XmcRAmwFAJ0bOFYj4gWg2VGa4l28kiDAkraQYACgl167
sRA33c8h7ZHS2qgAfgFmzkg=
=66Z0
-----END PGP SIGNATURE-----

В списке pgsql-general по дате отправления:

Предыдущее
От: Gregory Stark
Дата:
Сообщение: Re: Query with "like" is really slow
Следующее
От: "Filip Rembiałkowski"
Дата:
Сообщение: Re: work hour calculations