Re: MVCC and all that... - Mailing list pgsql-general

From Ellen Allhatatlan
Subject Re: MVCC and all that...
Date
Msg-id CAMLfE0NMosrY6__P-PVbV3yCLh1Gp1jWpqAm3oJ=PS3mh97oNg@mail.gmail.com
Whole thread Raw
In response to Re: MVCC and all that...  (Adrian Klaver <adrian.klaver@aklaver.com>)
Responses Re: MVCC and all that...
List pgsql-general
> Though I would like to know what happened in mid 2010?:
> https://github.com/FirebirdSQL/firebird/graphs/contributors

Yes, indeed, WTF? I'm not a member of the FB Illuminati - so I can't say!

> > OK again. I'm just wondering if the single file per database isn't a
> > fundamental architectural flaw in itself? AIUI, you could have
> > mulitple files (back in 32-bit land) "chained" - but (again AIUI) the
> > same table could be spread over x files - all "intermingled"... weird.

> What are you referring to above?

I'm sorry -  the single file flaw I was referring to occurs in FB and
has nothing to do with PG.

FB dbs are single files - or were - 32 bit - up to 2GB and then there
was another file. I don't know what happens for 64 bit - (note to self
- find out)!

So, you have table X - it has 2M rows (say, 0.5 GB) in the first file
(along with all the other tables). The 2GB limit is hit, more data is
added. 0.7 GB is added to table X - these records go into a new
database file - the table is split in two - you have 2 "extents" of
2GB with X split 0.5 - in extent1, 0.7 in extent2. All mixed up with
other tables as well!

That was the architectural flaw to which I was referring. Nothing to
do with PG, backups or anything like that - again, apologies for any
confusion - my phraseology wasn't the best! And I should have put what
I wrote elsewhere anyway!


-- 

El!



pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: MVCC and all that...
Next
From: Ron Johnson
Date:
Subject: Re: MVCC and all that...