Re: [PERFORM] [pgsql-advocacy] Postgres and really huge tables
A lot of data, but not a lot of records... I don't know if that's valid. I guess the people at Greenplum and/or Sun have more exciting stories ;) Not really. Pretty much multi-terabyte tables are fine on vanilla PostgreSQL if you can stick to partitioned and/or indexed access. If you need to do unindexed fishing expeditions on 5tb of data, then talk to Greenplum. http://www.powerpostgresql.com/Downloads/terabytes_osc2005.pdf -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PERFORM] [pgsql-advocacy] Postgres and really huge tables
Brian Hurt wrote: Is there any experience with Postgresql and really huge tables? I'm talking about terabytes (plural) here in a single table. Obviously the table will be partitioned, and probably spread among several different file systems. Any other tricks I should know about? We have a problem of that form here. When I asked why postgres wasn't being used, the opinion that postgres would just explicitive die was given. Personally, I'd bet money postgres could handle the problem (and better than the ad-hoc solution we're currently using). But I'd like a couple of replies of the form yeah, we do that here- no problem to wave around. It entirely depends on the machine and how things are accessed. In theory you could have a multi-terabyte table but my question of course is why in the world would you do that? That is what partitioning is for. Regardless, appropriate use of things like partial indexes should make it possible. Joshua D. Drake Brian ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PERFORM] [pgsql-advocacy] Postgres and really huge tables
Is there any experience with Postgresql and really huge tables? I'm talking about terabytes (plural) here in a single table. Obviously the table will be partitioned, and probably spread among several different file systems. Any other tricks I should know about? We have a problem of that form here. When I asked why postgres wasn't being used, the opinion that postgres would just explicitive die was given. Personally, I'd bet money postgres could handle the problem (and better than the ad-hoc solution we're currently using). But I'd like a couple of replies of the form yeah, we do that here- no problem to wave around. I've done a project using 8.1 on solaris that had a table that was closed to 2TB. The funny thing is that it just worked fine even without partitioning. But, then again: the size of a single record was huge too: ~ 50K. So there were not insanly many records: just something in the order of 10ths of millions. The queries just were done on some int fields, so the index of the whole thing fit into RAM. A lot of data, but not a lot of records... I don't know if that's valid. I guess the people at Greenplum and/or Sun have more exciting stories ;) Bye, Chris. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PERFORM] [pgsql-advocacy] Postgres and really huge tables
Chris, On 1/18/07 1:42 PM, Chris Mair [EMAIL PROTECTED] wrote: A lot of data, but not a lot of records... I don't know if that's valid. I guess the people at Greenplum and/or Sun have more exciting stories ;) You guess correctly :-) Given that we're Postgres 8.2, etc compatible, that might answer Brian's coworker's question. Soon we will be able to see that Greenplum/Postgres are handling the world's largest databases both in record count and size. While the parallel scaling technology we employ is closed source, we are still contributing scaling technology to the community (partitioning, bitmap index, sort improvements, resource management, more to come), so Postgres as a bet is likely safer and better than a completely closed source commercial product. - Luke ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
