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

From: Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>
To: Ow Mun Heng <Ow(dot)Mun(dot)Heng(at)wdc(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Column as arrays.. more efficient than columns?
Date: 2007-09-07 12:07:44
Message-ID: 46E13F10.3020000@cox.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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-----

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Gregory Stark 2007-09-07 12:08:59 Re: Query with "like" is really slow
Previous Message Martijn van Oosterhout 2007-09-07 12:05:49 Re: Type cast text to int4