Re: [PERFORM] perf problem with huge table

Dave Crooke wrote: > On Wed, Feb 10, 2010 at 5:30 PM, Jon Lewison > wrote: > > > > Just a nit, but Oracle implements MVCC. 90% of the databases out > there do. > > > Sorry, I spoke imprecisely. What I meant was the difference in how the > rows are stored i

Re: [PERFORM] perf problem with huge table

> Hi all, > > i am trying to move my app from M$sql to PGsql, but i need a bit of help > :) Except from all the other good advises about partitioning the dataset and such there is another aspect to "keep in mind". When you have a large dataset and your queries become "IO-bound" the "tuple density"

Re: [PERFORM] perf problem with huge table

rama wrote: in that way, when i need to do a query for a long ranges (ie: 1 year) i just take the rows that are contained to contab_y if i need to got a query for a couple of days, i can go on ymd, if i need to get some data for the other timeframe, i can do some cool intersection between the

Re: [PERFORM] perf problem with huge table

Actually, in a way it does "No space left on device" or similar ;-) Cheers Dave P.S. for those not familiar with Oracle, ORA-01555 translates to "your query / transaction is kinda old and I've forgotten the data, so I'm just going to throw an error at you now". If you're reading, your SELECT

Re: [PERFORM] perf problem with huge table

On Wed, Feb 10, 2010 at 4:48 PM, Dave Crooke wrote: > On Wed, Feb 10, 2010 at 5:30 PM, Jon Lewison wrote: > >> >> >> Just a nit, but Oracle implements MVCC. 90% of the databases out there >> do. >> > > Sorry, I spoke imprecisely. What I meant was the difference in how the rows > are stored inte

Re: [PERFORM] perf problem with huge table

On Wed, Feb 10, 2010 at 5:30 PM, Jon Lewison wrote: > > > Just a nit, but Oracle implements MVCC. 90% of the databases out there do. > Sorry, I spoke imprecisely. What I meant was the difference in how the rows are stored internally in Oracle, the main tablespace contains only the newest v

Re: [PERFORM] perf problem with huge table

On Wed, Feb 10, 2010 at 4:16 PM, Dave Crooke wrote: > Hi Rama > > I'm actually looking at going in the other direction > > I have an app using PG where we have a single table where we just added a > lot of data, and I'm ending up with many millions of rows, and I'm finding > that the single

Re: [PERFORM] perf problem with huge table

Hi Rama I'm actually looking at going in the other direction I have an app using PG where we have a single table where we just added a lot of data, and I'm ending up with many millions of rows, and I'm finding that the single table schema simply doesn't scale. In PG, the table partitioning

Re: [PERFORM] perf problem with huge table

On 2/10/2010 5:13 PM, rama wrote: > in that way, when i need to do a query for a long ranges (ie: 1 year) i just > take the rows that are contained to contab_y > if i need to got a query for a couple of days, i can go on ymd, if i need to > get some data for the other timeframe, i can do some co

[PERFORM] perf problem with huge table

Hi all, i am trying to move my app from M$sql to PGsql, but i need a bit of help :) on M$sql, i had certain tables that was made as follow (sorry pseudo code) contab_y date amt uid contab_yd date amt uid contab_ymd date amt uid and so on.. this was used to "solidif