Re: Questions about Postgres and Oracle
Date: Thu, 20 Dec 2012 08:58:12 -0800 (PST)
Message-ID: <1356022692.98218.YahooMailNeo_at_web162805.mail.bf1.yahoo.com>
Greenplum's divisional performance in that time frame would likely not have been public information since we were under EMC's umbrella at that time.Worrying about that aspect of Greenplum would be about the same as worrying about Sun's miserable (continued) slide into the abyss (which should invoke the image of a big thing crashing down rather than a small thing climbing up). The OP was about limits. Greenplum limits a table to 128 TB per partition per segment. I'm working on a phase 1 POC right now with 64 nodes running 512 segments. If I don't use table partitioning I'll only be able to load 65,536 TB of data. The table is partitioned by the way and 64 nodes with 512 segments (1,024 E5-2660 cores) is 1/5th the size of our largest node-count customer (that I am aware of).
In other words, big isn't the problem.
With that I'll cease my activity on this thread so as to not wound tender sensibilities. Feel free to ping me directly if you want more information.
From: Paresh Yadav <yparesh_at_gmail.com> To: Kevin Closson <ora_kclosson_at_yahoo.com> Cc: kyle Hailey <kylelf_at_gmail.com>; "jkstill_at_gmail.com" <jkstill_at_gmail.com>; Sandra Becker <sbecker6925_at_gmail.com>; oracle-l <oracle-l_at_freelists.org> Sent: Wednesday, December 19, 2012 6:59 PM Subject: Re: Questions about Postgres and Oracle
Kevin,
Fortunately me too :) (didn't start the thread to offend the OT police.)
Thanks for sharing this interesting info. I didn't know about EMC Greenplum UAP can do that, that sounds awesome. What other products can do so (EnterpriseDB)? I didn't see that as being marketed heavily by Greenplum (thousands of partitions) so I always assumed that they scale to large size dbs by clustering.
On the flip side we found a very depressing critique of Greenplum's financial results (which I read in I believe 2011 Nov/Dec time period and I have it saved somewhere to cover my back ) and wondering if this might reflect on the product's strength, stayed away. We don't have a big shop to evaluate a product so we depend on search data for level 1 evaluation. Looks like we missed a very important product in our evaluation (it is by design as we don't have lots of warm bodies to do trial and error). I will give this another look, thanks again!
PS - I believe even though this oracle-l, it is okay to discuss Postgres as long as it is in compared to capabilities of Oracle database.
Paresh
On Wed, Dec 19, 2012 at 9:01 PM, Kevin Closson <ora_kclosson_at_yahoo.com>wrote:
>
> Beyond 100 partitions per instance, one needs to go for clustered Postgres
> database solution and it brings with it all the challenges of a distributed
> databases that NoSQL databases try to solve by staying within compromise
> that were postulated in CAP theorem (
> http://www.julianbrowne.com/article/viewer/brewers-cap-theorem ).
>
> ...I didn't start the thread so I hope to not upset the OT police.
>
> Paresh, at the scale you speak of you need to consider one of the product
> that embeds PostgreSQL and breaks down those walls. Once such product is
> EMC Greenplum UAP. If you want thousands of partitions on a table or even
> on a single column you can do so with that product. Greenplum customers are
> routinely petabyte sized and at the core of that is an adapted PostgreSQL
> kernel.
>
> Now, since this is oracle-l I'll stop there.
>
>
>
>
>
-- Thanks Paresh 416-688-1003 -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Thu Dec 20 2012 - 17:58:12 CET